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1 .1 . Document Scope 

This document serves as a design and maintenance document for the Reachability & Control Subsystem of 
the *'Coverage-based Test Generation" product (CTG). This document describes various mechanisms, 
techniques, and policies which are used to coordinate formal and informal engines as a solution to our 
specific reachability problem. This includes interfaces to the engines and integration techniques for those 
engines. 

This document does not describe in detail individual engines or underlying infrastructure of the formal 
analysis environment. The document does not describe detailed User Interface issues, mechanisms, 
methodologies, or flows. VERA environmental modeling and compilation is not discussed. Refer to 
appropriate documentation for those other technologies. 

1.2. Intended Audience 

The intended audience is technical engineering staff which are actively involved in CTG development. 
The document may be useful for non-technical persons who are familiar with CTG problems and issues, 

1 .3. Document Organization 

The remainder of this document is organized in the following way. Section 2 provides an overview of the 
problem CTG addresses and the general approach from a users perspective. Section 3 provides an 
architectural overview of the CTG system implementation. Section 4 provides detailed descriptions of 
mechanisms used to coordinate, control, and/or integrates the various engines and UI into a cohesive 
system. Section 5 provides detailed descriptions of goal creation and maintenance in CTG. Section 6 
provides detailed interfacing mechanisms for the UI process. Section 7 provides detailed descriptions of 
the interface with the explicit states simulator VCS, as well as detailed explanation of test generation and 
replay mechanisms and capabilities. 




The basic problem that CTG attacks is the following. Given some Design Under Test (DUT), and some 
goal states of that design, classify all goals as either Unreachable or Reached. If a goal is classified 
Unreachable, it must be proven with respect to some start state and DUT environmental conditions. If a 
goal is Reached, then CTG must save a simulation test suitable to reach that goal in some later VCS stand- 
alone session. Any goal which is not classified as Reached or Unreachable is said to be Unknown; CTG 
attempts to minimize the number of these Unknown goals. 

CTG uses a state coverage metric, hence goals are states, or sets of states, of the design These states are 
defined by a small number of "coverage variables". These coverage variables are on the order of dozens, 
while the total latches in the design are in the thousands. Each goal is a different combination of these 
coverage variables. As an example; given coverage variables {cl, c2}, CTG attempts to reach "states" 
{00}, {01 }, { 10), { 1 1 }. Note that these "states" are technically "cubes", but we call them states. 

The CTG objective then is to classify as many different combinations of these coverage variables as 
possible. This task is known as "Coverage Driven Test Generation". 

The method CTG uses to "reach" (or cover) goals is to interleave classic explicit state simulation (e.g. 
VCS) with formal exhaustive searches using some explicit design states as starting points for the search. If 
a formal search is successful, then the explicit state simulator is used to build up a simulatable test which 
reaches the goal. This scenario is illustrated in Figure 1. In Figure 1, the enclosing box represents the 
entire state-space of the design. Explicit state simulation is represented by the zig-zag solid line as explicit 
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states are visited on each successive clock cycle. Stars represent goals which are to be "reached", if 
possible. 

At some time Tl, CTG determines that simulation is not reaching new goals. A formal search is used to 
exhaustively search for a goal from some explicit state, SI, generated by the simulator. This formal search 
is represented by the concentric rings in Figure 1 . When a formal search reaches a goal Gl, the sequence 
of input assignments (termed a "trace") to reach from SI to Gl are simulated and the goal is then 
"reached". 

This interleaved process continues until all goals are classified or some user-specified resource limit is 
exceeded (typically time). 




SI @T1 



Figure 1. CTG Search Process 
Some basic observations which lead to this interleaved engine usage are the following: 

• Explicit state simulators are very efficient at reaching "deep" states in the 
design. Explicit state simulation only reaches a single state at each clock 
cycle. 

• Formal search methods are exhaustive, which means that all reachable 
simulation states are reached at the same time. Formal reachability 
algorithms are feasible for short search radius, and commonly intractable 
for deep search radius. 

• When a difficult goal is reached, there are often several other goals "close" 
to that goal in the state-space. This is termed "jackpot" behavior. The 
rationale for this is due to the nature of the goals that CTG attempts to 
reach. As described earlier, goals consist of a collection of coverage 
variables. These coverage variables are the union of smaller control Finite 
State Machines (FSM's) in the design. Some of these FSM*s are relatively 
easy to transition to new states, others are relatively difficult. When a 
difficult FSM state is entered, the cross states determined by the easy 
FSM's are then easily reached; these are the jackpot goals. 



4 



This section provides a general description of large components of the CTG systeni which accomplish the 
usage described in the previous section. 



3.1 . Master/Slave Infrastructure 

The overall CTG architecture may best be thought of as a Master/Slave where a Master 
process interacts and coordinates many concurrent Slave processes. These Slaves are 
used to "reach" various goals, prove them unreachable, and to interact with the user. Fig. 




2 illustrates this architecture. 



Figure 2. CTG Process Architecture 



As illustrated in Figure 2, a "Master" process is used to coordinate more than 1 Slave (or 
child) processes so that the User interface process is isolated from all 
control/coordination problems. The Master process is also given the task of providing 
communication mechanisms between the Slaves and UI process. In addition, various 
system heuristics are embodied in the Master process to choose which Slave engine to 
use^t different times in the CTG session. 

It is important to note that the Master process is intended to be "live" at all times; the 
Master process does not "block" for long times while various analysis are carried out by 
any given Slave. An additional requirement is that the Master process allow Slaves to 
work concurrently. 

The Master process continually polls the Slave and the UI processes for messages and/or 
conmiands to be processed. When a message is received from a Slave, it is decoded and 
either processed by the Master process itself, or passed to the UI. Coimnands from the 
UI are processed immediately by the Master process. 



5 



The Slave processes of Figure 2 represent various reachability and/or unreachability 
engines, each running in a separate unix process. Examples of these engines in the CTG 
system include: symbolic simulation, discrete event simulation (VCS), satisfiability 
solver, and an image computation engine. Depending on usage, it is possible for 2 or 
more of these engines to be used in parallel within a single CTG analysis session. 

3.2, TCL Control Mechanisms 

Control flow for the CTG product is embodied in TCL procedures which execute in the 
Master process. This TCL control code interacts with Slave processes and the UI process 
to coordinate all Slaves into a coherent CTG session. 

Each Slave process receives commands from the Master process via stdin of the Slave 
process. The Slave communicates with the Master by writing properly formatted text 
strings to stdout, or by putting large amounts of data (e.g. BDDs) in data files formatted 
for the specific task at hand. 

Two classes of messages are received by the Master process from Slave processes: 
formatted and unformatted. Unformatted messages are simply printed to stdout of the 
Master process. Formatted messages from the Slave are, by definition, intended to be 
processed by the TCL control program running in Master. The Master process transfers 
this information from the unix/C world to the TCL world by calling a TCL procedure; 
this procedure then further decodes the message for handling by the TCL control 
program. A message "catalog" is maintained such that all pre-defined (thereby 
formatted) Slave messages are known. 

3-3. UI Interfacing 

The UI process issues commands to stdin of the Master process, and receives formatted 
messages from stdout of the Master process. The UI process is responsible for all user 
presentation of data received from the Master process. This presentation may be either 
graphic or textual in nature, depending on user needs. A UI message catalog is 
maintained. 

3.4. Reachability Engines 

CTG uses a number of reachability engines, each running in its own unix Slave process. 
Each of these engines use specialized algorithms to search for sequences of inputs which 
lead from one state (a "start" state) to others ("goal" states). Examples of these 
reachability engines include: 

• Explicit state engine. This is a classic event driven or cycle-based 
simulator. This engine uses biased, constrained, random simulation 
techniques to exercise the Design Under Test (DUT) in an attempt to reach 
goal states. In addition, this engine has the capability to: 

• generate start states for searches performed by other, more *f ormal", 
engines, 

• apply sequences of inputs which are generated by the formal engines, 

• save the entire testcase for later re-use by the user 

• Symbolic Simulation engine. This engine uses exhaustive (perhaps under- 
approximated) symbolic simulation methods to attempt to reach goals from 
specific starting states. If a goal is reached, the engine saves a sequence of 
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inputs which are replayed by the explicit state engine to prove that the state 
has been reached. 

Satisfiability Solver engine. The SAT engine uses bounded model checking 
concepts, together with classic satisfiability techniques, to reach goals from 
a starting state. If successful, the engine saves a sequence of inputs which 
are replayed by the explicit state engine to prove that the state has been 
reached. 



3.5. Unreachability Engines 

Unreachability engines use various formal techniques to prove that certain goal states are 
not reachable from some start state. The start state of interest is typically the reset state 
of the DUT. These Unreachable states are then optionally communicated to the 
reachability engines to reduce the search problem. Current unreachability engines 
incude: 

• Image Computation Engine. This engine computes an approximate fixed 
point for reachable states, then inverts the fixed point as a proof of 
unreachable states. The fixed point computation is typically over- 
approximated. 

3.6. CTG Process Flow 

An illustration of the interleaved and concurrent nature of the CTG system is illustrated 
in Figure 3. 
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Figure 3, Interleaved CTG System Overview 

The diagram of Figure 3 shows an abbreviated, simplified CTG session where VCS, 
Symbolic Simulation, and Unreachability analysis collaborate to classify goals. The 
vertical solid arrows indicate that the unix process is **working". The vertical dashed 
arrows represent that the unix process is waiting for input from some other process before 
continuing. The horizontal double-arrows indicate messages and/or data being passed 
between unix processes. 



A description of some of the interesting transactions and tasks follows. Note that all UI 
interactions are omitted, as they are specific to another document. 



1 - The first thing that happens is that the Master process is invoked. After 
invocation, the Master process loads HNL, defines goals, and generally 
does initialization type things. 

2. At some point, based on input from the user, the Master process starts and 
initializes forma] reachability engines in separate unix Slave processes. In 
this example, only the Symbolic Simulation engine is used. The hv 
program which embodies this reachability engine loads HNL, defines goals, 
and builds the Symbolic Simulation Manager. 

3. The Master process, again under UI direction, starts the VCS Slave process. 
VCS initializes, loads goals, performs a reset sequence, then runs a number 
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of random simulation cycles. At this point, the CTG-resident code in VCS 
is keeping track of which goals are being 'Veached". At some point, CTG 
PLI code in VCS determines that "goals are not being reached", VCS stops 
and returns control to the Master process. 

4. The Master process, based on various heuristics and user parameters, makes 
a decision on how to proceed. In this example, the decision is to perform a 
reset sequence then do more random simulation in VCS. 

5. VCS performs a reset sequence to reset the DUT, then more random 
simulation occurs. After determining that no more goals are being reached, 
VCS stops simulating and returns control to the Master process. 

6. The Master process decides to perform a formal search, using Symbolic 
Simulation, from the current design state. This design state is written from 
VCS and is used to 7) start unreachability analysis, and 8) start a formal 
search. 

7. An Unreachability Slave is started. This is performed by the hv program, 
which loads HNL and goals, then performs a fixed point computation from 
the design state provided from VCS. After the fixed point is computed, 
those goals outside the fixed point are proven unreachable. These 
unreachable goals are written to disk for later processing by other Slave 
engines. 

8. Simultaneously with unreachability analysis, a formal search is initiated 
using the Symbolic Simulation engine. This search starts from the design 
state captured by VCS. In this scenario, the search completes successfully, 
and the Symbolic Simulator writes out primary input stimulus (i.e. a 
"trace") which VCS can use to drive the design from the current state to the 
goal state. 

9. VCS replays the trace and hits the new goals. Random simulation continues 
in an attempt to hit the previously described "jackpot" goals. 

10. While VCS is performing random simulation (trace replay, etc), the 
unreachability engine completes and results are incorporated into the Master 
process. This unreachable goal data will be communicated to each of the 
reachability engines on an as-needed basis. 

11- At some point, VCS determines that no more goals are being hit, and 
control is returned to the Master process. 

12. The VCS process is sent a message which contains the number of 

unreachable goals. This count is used to adjust the coverage metric which 
tells VCS when all goals have been classified. 

The CTG session continues interleaving VCS and Symbolic Simulation until all goals are 
reached. The remainder of this document explains the details about how these things are 
implemented. 




As illustrated in Fig. 2, the Master process is the central coordinator of a multi-process concurrent system 
which attempts to classify goals in some sort of efficient manner. TCL procedures are implemented to 
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provide key coordination of the Slave engines, and to embody heuristics to attempt to provide an efficient 
coherent system to the UI. Important infrastructure services are provided in C code packages to provide 
flexibility to the TCL control programs. The hv program provides this Master process by invoking it the 
following way: 

• hv -I -master 

• Typically this invocation is performed by the UI process which 'fork's a 
Unix process, then *exec's the hv executable in it. 

This section presents detailed descriptions of the mechanisms which accomplish the Master process 
capabilities. 

4.1 . Process Hierarchy and Communication 

The process hierarchy of Figure 2 is the following. The Master process is started by the 
UI process. Slave processes are started by the Master process. These processes are 
started using standard unix 'fork' and *exec* mechanisms. 

When a child process is started, the parent process redirects standard-in and standard-out 
of the child process into unix pipes which are then read and written by the parent process. 
Thus conununication from the parent to the child is accomplished as the child process 
reads from its stdin file descriptor. The Master and most Slave processes execute the hv 
program which processes stdin using the Synopsys cci TCL interpreter. The VCS Slave 
uses the VCS interactive interpreter to read from stdin. Thus all messages to child 
process must be as either TCL hv commands or VCS commands, depending on the child. 

Messages from a child to a parent are communicated via writing to stdout of the child 
process. The parent process must periodically read from die earlier-mentioned pipe to 
retrieve and process these messages from the child. 

In some cases, where large amounts of data are needed to be communicated between 
processes, it has proven useful for the data provider to write the data to a temporary file. 
The consumer is then sent a message saying what/where the data is. The consumer of the 
data opens the temporary file and processes the data. 

4.2. Infrastructure Package (hvCtI) 

The hvCtl package provides the key mechanisms to start Slave process, coordinate them, 
and relay messages to either the UI process or TCL procedures resident in the Master 
process. Services are provided to allow the TCL programs to communicate and track 
progress of the Slave processes. These services are accessed exclusively by TCL code 
which runs in the Master process. This section presents key concepts and commands 
which access the implementation of those concepts. 

4.2.1. Channels 

A **Channel" defines a communication path between the Master process and a Slave 
process. Each Channel has a unique ID which is assigned at the time the Slave process is 
started. This unique ID is then used to send commands to that Slave and to identify 
messages received from the Slave. Commands to manipulate and interact with a Channel 
are the following: 

• hvctLchanneLopen - This conmiand opens a channel by starting a user- 
specified program in a separate unix process. The Master process then 
sends messages to the Slave via the hvctl_send_message command. 



10 



Messages/responses from the Slave will then be read from stdout of the 
child process. Upon success, this command assigns a unique ID for for 
TCL usage to identify the new Channel. Input arguments to the comjnand 
allow specification of the program to start in the new process, the working 
directory the process is to run in, and up to 6 arguments to be used in 
invocation of the program which is started. 

• hvctl_channeI_close - This command closes a channel and cleans up data 
structures associated with it in the Master process. Input arguments are the 
Channel ID, and an optional command which terminates the program 
running in the Slave process. 

• hvctLchannel_send„msg - This conmiand sends a message to the program 
running in the Slave process. Input arguments are the Channel ID and a 
string which is sent to stdin of the child process. The message string must 
be a syntactically and semantically correct conmiand for the program 
running in the Slave process. The message is presented to that program on 
stdin of the Slave process. 

• hYctl__channel_stack_set - Due to the concurrent, non-blocking nature of 
the CTG system, a mechanism is needed to allow long-duration Slave 
conmiands to execute. The problem for the controlling TCL program then 
becomes **remembering" what is happening in a Slave process over a long 
period of time, and what needs to be done when that task is finished. The 
mechanism provided is termed a "Command Stack", which is described 
later in this document. This conmiand associates a Command Stack with a 
specific Channel. Input arguments are the Channel ID and the name of the 
Command Stack to associate with it. 

• hvctl_channel_stack_get ~ This command returns the name of a Command 
Stack associated with a specific Channel. If no Command Stack has been 
assigned, the string "<no_stack>" is returned. 

• hvctl_channeLdump Jnfo - This command is provided for debugging 
purposes and prints various information about an open Channel. 

4.2.2. Engines 

An Engine is a "bookkeeping" aid which exists in the Master process, and defines a 
mechanism which is resident in a Slave. For example, a "Symbolic Simulation Engine" 
object might exist in the Master process, and correspond to an entire Slave process which 
is used to perform Symbolic Simulation. 

This corresponding Slave mechanism performs some sort of analysis or task which may 
or may not involve a number of individual commands/responses between Master and 
Slave. It is possible (and conmion) to have multiple Engines associated with a single 
Slave process at the same time. Examples of Engines are the Symbolic Simulator or SAT 
solver. 

Note that the Engine concept is very general, and it has proven useful to have more 
abstract Engines such as the Goal Manager, the Design-Under-Test Manager, etc. 

Engines may have state; for example, the Symbolic Simulation Engine might be in the 
"RUNNING" state, or the "IDLE" state. This state concept has proven useful to help the 
controlling TCL program deal with the non-blocking, concurrent nature of CTG. 
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• hvcU_engine_type_define - This command defines a new type of Engine. 
Typically all Engine types are defined at Master process startup. 

• hvctl_engine_state_define - This command defines a legal state for the 
newly-defined Engine type. Valid Engine states are typically defined at 
Master process startup, when the new Engine type is also defined. 

• hvctl„engine_start - This command creates an instance of an Engine type, 
associated with a specific Channel. The user specifies Engine type, 
Channel ID, and a name the Engine instance will be known by. The 
combination of type, Channel, name must be unique. 

• hvctl_engine_state_set- This command assigns a state to an instance of an 
Engine. The state must be valid (defined with hvctl„engine_state_define) 
for the Engine type. If the specified state is invalid, an error occurs. The 
caller must specify a unique combination of Engine type, name, and 
Channel ID, 

• hvctLengine„state_get - This command returns the current state of a 
specific Engine. The caller must specify a unique combination of Engine 
type, name, and Channel ID. 

• hvctl_engine_exists - This command returns a space-delimited list of 
names of current Engines which match caller specified parameters. For 
example, the caller can request "All Engines defined for Channel ID=4", or 
**AI1 Engines of type Symbolic Simulator". If no Engines are found, the 
empty string is returned. 

• hvctl_engin€_stack_set - This conmiand is analogous to the previous 
hvctl_channel_stack_set command. The caller specifies a Command 
Statck, and unique combination of Engine type, name, and Channel ID. 

• hvctl_engine_stack_get - This conunand returns the name of the 
Command Stack associated with a specific Engine. The caller must specify 
a unique combination of Engine type, name, and Channel ID. 

• hvctl_engine_type_duinp - This is a debugging command which prints 
various information about a valid Engine type. 

• hvctLengine_dump Jnfo - This is a debugging conunand which prints 
information about a current Engine instance. 

4.2.3. Command Stacks 

As mentioned earlier, the non-blocking nature of the Master process leads to an 
interesting problem when the Master asks the Slave process to execute a time-consuming 
task. The TCL control program cannot launch a long task, then simply block-and-wait 
for the task to finish before continuing to the next task in a sequence of tasks which need 
to be completed. The TCL program must not block; this non-blocking requirement 
allows for interactions with the UI or other Slaves. Yet somehow, the TCL program 
needs a convenient mechanism to help remember what to do when the time-consuming 
Slave task finishes. The Command Stack is the key mechanism provided to assist in this 
problem. 
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A Command Stack is a stack of commands which may be attached to either a Channel or 
an Engine, When a task is finished (detected via a message from the Slave), the next 
command is popped from the stack and is executed. Common usage by the TCL control 
program include the following: 

• A new Command Stack is created and associated with each Channel when 
the Channel is opened. 

• When a time-consuming task is started by a Slave, a TCL procedure, with 
necessary arguments, is pushed onto the Command Stack for that Channel. 
This pushed TCL procedure is to be executed when the time-consuming 
task is completed. 

• Optionally, the state is set on the Engine which will signal completion of 
the time-consuming task, 

• When the task-is-done message is received by the Master process, the 
command is popped from the Command Stack, and it is executed. Note 
that this Slave-to-Master message passing is explained later in this 
document. 

The remainder of this section describes conmiands which directly manipulate Command 
Stacks. 

• hvctLcominand_stack_create - This command creates a new Command 
Stack. The caller may optionally assign a name to the Command Stack - if 
so, the name must be unique. 

• hvctI_coinmand_stack_free ~ This command destroys a previously- 
created Command Stack. 

• hvctl_coimiiand_stack_push - This conunand pushes a syntactically legal 
TCL conmiand string onto the conmiand stack. This string is executed at 
some later point using the TCL "eval" mechanism. 

• hvctI_command_stack_pop - This command pops the top command string 
off the Command Stack. If the stack is currently empty, the string 
"<empty>" is returned. 

• hvctl_cominand_stack_duinp - This debugging conmiand prints 
information about a current Command Stack. 

4.2,4. Message Poll Loop 

As illustrated Figure 2, the Master process needs to continually check for messages from 
the UI process as well as each of the Slave process. This mechanism uses the unix 
"select" mechanism to accomplish this, "select" is a unix function which is given a set 
of open file descriptors to attempt to simultaneously read from. When data is read from 
one of the files, select returns with the file descriptor of the file with waiting data. The 
select function has the ability to also "time out" if no file may be read after a certain 
amount of time. 

For the Master process, these files are either stdin of the Master process, or the open 
"pipe" (another unix-ism) for individual Slave processes. These pipes are created when a 
Slave process is started, and correspond to stdin and stdout of the Slave process. 
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When data is read from one of these files, the Master process first determines which file 
the data is read from. If the file is the output of a Slave process, the text is decoded to 
determine if the message is formatted in such a way as to be intended for the TCL 
mechanisms in the Master process. Formatted Slave messages are identified by 
prepending "HVINFO" and a message ID to the actual data. The message ID is 
associated with a specific engine and is expected to be understood by the TCL control 
program in the Master process. 

Once the active file and message decoding has been performed, the Master process takes 
the following action: 

• If the data is read from stdin, it is a TCL command from the UI process 
which needs to be executed. The Synopsys cci command interpreter is 
used to execute these commands. 

• If the data is read from a Slave process, the message is either unformatted or 
formatted. Unformatted text is relayed to the UI by simply writing the text 
to stdout of the Master process. Formatted messages are communicated to 
the TCL control program in Master by calling a predefined TCL procedure. 
The TCL procedure is called "hv_child_msg_recv" and arguments include 

• Channel ID for the Channel which sent the message, the message ID, and 
the actual text of the message. 

4.3, TCL Coordination Package 

The CTG control policies, mechanisms, and heuristics are all implemented in TCL 
procedures which are executed by the "hv" program running in the Master process. This 
TCL control code must issue commands to the Slave programs, interact with the UI 
process, track progress of die test-generation session, etc. This task is complicated, and 
key aspects are described in this section; it is beyond the scope of this document to 
explain all necessary details. 

Note also that this TCL code is dynamic in nature (i.e. it changes often) as heuristics and 
algorithms change. 

4.3.1. Messages and Message Handlers 

As previously discussed, when the Master process reads a message from a Slave process, 
this message may need to be communicated to the TCL control program. This is done by 
a call to the TCL procedure "hv_child„msg_recv" which includes a unique message ID, 
the Channel ID the message is from, and the actual message itself. 

Messages are defined on an Engine-specific basis, and are used to communicate some 
data and/or status from a Slave to the TCL control program in the Master process. These 
messages must obviously be unique, and coordination of message ID/content between the 
Slave implementation and Master TCL code must be coordinated by the developer of the 
engine (Slaves issue messages, Master receives & processes them). To help with this 
coordination, each Engine has a separate TCL procedure where all messages for that 
Engine are defined and handled. The hv_child_msg_recv procedure decodes message 
ID enough to decide which Engine-specific message handler to call, then that procedure 
is called with the message for further processing. 

Message Ids are textual, and the collisions are avoided between engines by assigning a 
unique prefix to all messages for that engine. For example, ail messages from the VCS 
engine are of the form "VCS_<MsgName>" where <MsgName> varies for each message 
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from the VCS engine. These textual prefixes are documented for all known engines in 
the hvRecipe.tcl file. 

(Developers note: At time of writing this document, message Ids are numeric, and the 
actual message format includes a data type field. This will soon be modified to reflect 
the format described in this document.) 

To add a new Engine, the developer must perform the following tasks: 

1 . Create a file <Engine>Handler.tcl and put it in /vobs/propver/src/tcL This 
file will implement the Engine-specific message handler TCL procedure 
hv„<Engine>_child_msg_recv. This file also contains the Engine type and 
valid states definitions. Allocate a textual message ID prefix for the new 
Engine, and document it in hvRecipe.tcl. 

2. Modify the hv_child_msg_j:ecv procedure in hvRecipe.tcl to recognize 
your new messages and call your new procedure when a message in the 
proper range is detected. Source the <Engine>Handler.tcl file where all the 
other message handlers are sourced, at the end of hvRecipe.tcl. 

3. Document your new messages and handle them by implementing the 
hv_<Engine>_child_msg_recv procedure in the < Engine>Handler.tcl file. 
Stylistically, use one of the pre-existing *Handler.tcl files in the tcl 
directory as a template. By convention, this file does not "know" about 
other engines or high-level procedures. This message handler typically 
interprets messages, sends notice to the UI, sets engine state, then pops 
high-level commands off the command stack to continue the CTG session. 

4. Instrument the corresponding Slave implementation of the Engine to 
generate messages in a semantically appropriate manner. 

5. Modify the control program TCL code in hvRecipe.tcl to use the new 
Engine in an appropriate way. This code is discussed in the following 
section. 

At the time of writing of this document, a certain number of Engines have been defined 
and integrated. Those engines and their usage are: 

• Symbolic Simulation Engine, This Engine is implemented in the hv 
executable and performs Symbolic Simulation from some start state in an 
attempt to reach some pre-defined goals. If a goal is reached, a **trace" is 
written for VCS use which applies a sequence of input to drive the design 
from the start state to the jgoal state. 

• VCS Simulation Engine. This Engine is implemented via PLI code 
attached to the VCS simulator. This Engine is responsible for observing 
which goals have been reached as simulation progresses, detecting points at 
which random simulation should stop, testcase generation and replay, and 
interfacing with the user-written environmental biasing and constraint code. 
In addition, this Engine is capable of conveying search start states to the 
formal reachability engines. 

• SAT Engine. This Engine is similar to the Symbolic Simulation Engine 
except that satisfiability techniques are used to attempt to find a sequence of 
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inputs jfrom some start state to a goal state. This Engine is implemented in 
the hv executable. 

• Image Computation Engine. This Engine uses symbolic state traversal 
techniques to prove that certain states are unreachable from specific start 
states. These provably unreachable states are then used to classify goals 
which are unreachable. This Engine is implemented in the hv executable. 

• Goal Engine. It has proven useful to define a Goal Engine to manage goal 
creation, update, and coordination between the various Slave process and 
the Master process . This Engine is implemented in the hv executable. 

• DUT Engine. A DUT Engine is used to manage the design load and pre- 
processing steps which lead up to reachability and/or unreachability 
analysis. This Engine is implemented in the hv executable. 

4.3.2. Session Startup 

Refer to a Ul-related document for detailed description of user interactions with the CTG 
system (i.e. "how the User interacts with CTG"). In general, the user will first setup an 
analysis session by doing things like creating hnl, compiling the simulation model, 
defining goals, environmental modeling, etc. FoUov/ing this, the user clicks on "Generate 
Testcase" and the following sequence of events take place: 

• The UI starts the Master process by forking a child process and invoking 
"hv -I -master" in that process, llie UI opens a pipe to read/write 
stdout/stdin of the Master process. 

• The UI issues hv conmiands to setup the Master process. These commands 
must accomplish the following: 

• The hvRecipe.tcl file needs to be sourced 

• User-specified session parameters (i.e. TCL knobs) must be set. These 
parameters are discussed in a later section, but this step basically sets a 
number of pre-defined TCL variables. 

• The HNL must be loaded into the Master process by calling the 
hvino_create_hnl_design command. 

• The HvDsg must be created, and any necessary preprocessing must be 
accomplished. This is done using the hvdsg__create_hv_design 
command. Note that current HvDsg usage is that both a hierarchical 
and flat HvDsg are created in the Master process. All formal and 
analysis is performed using the flat design; the hierarchical design is 
used for interaction with the user. Conmiands are provided for 
mapping between flat and hierarchical worlds. 

• The proper HvMch should be created using hvmch_create_machine. 

• An appropriate cover (HvCic) should be created using 
hvcic_create_cover 
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• An SthMgr and OrdMgr must be created using hvsth_create_manager 
and hvord_create„manager 

• The user-specified goals are created in the Ma'ster process. 

• The UI process requests a Slave process to be started for SAT and/or 
Symbolic Simulation analysis. This is accomplished by a call to the 
**hv_setup_formar' TCL procedure. This procedure is defined in 
hvRecipe.tcl and described later in this document. A Slave process is 
started, hni loaded, goals defined, and any algorithm-specific setup is 
performed (e.g. create the Symbolic Simulation Manager). 

• The UI initiates actual test generation by launching VCS in its own Slave 
process. This is done by calling the TCL procedure: 
"hv_start_vcs_session'\ This procedure is defined in hvRecipe.tcl and 
described later in this document. A Slave process is started and the 
compiled simulation model (generated by VCS compilation earlier) is 
started. Goals are loaded in VCS and a reset is performed, then simulation 
pauses. The Master process then sets up simulation stop conditions (via 
calls to the CTG PLI code) and initiates a simulation run fi-om the reset 
state, 

• At this point, the CTG PLI code within the simulator is recording goals 
which are reached, as well as any information needed to later write out the 
final testcase. 

From this point on, the CTG session progresses according to the "Phase Progression" 
described in the following section, 

4.3,3. CTG Analysis "Phase" Progression 

After the reachability session is initiated, the resultant actions are highly dependent on 
various heuristics, user-specified direction, and how "hard" the design and/or goalset is. 
In general, the session progresses through a number of phases or modes. These phases 
are designed to in general be progressive in CPU and Memory cost. 

This section describes the phase progression. Search Engine usage in those phases are 
described as are exit conditions for the phase. Note that this progression is the heart of 
CTG and can be expected to change "A LOT" as CTG is exposed to more designs and 
the development team learns how to effectively use all the technology. This section is 
provided to give the reader a feel for how things worked at least once in the past. 

A CTG reachability session transitions through the following phases in order. At any 
point, if all goals have been reached, then the testcase is written and the system stops. In 
the following discussion, certain user settings (i.e. "Knobs") are referenced; these knobs 
are cataloged and described elsewhere in this document. In the following discussion, 
knobs are italicized and in bold. 

• MODE_INIT 

This is the initial mode that CTG starts in. The VCS Engine is used to repeatedly reset 
the design followed by a number of biased random simulation cycles. The number of 
times to repeat this sequence is specified by initRunsMax and the number of simulation 
cycles to run is specified by initCycles, initCycles specifies that VCS will stop when 
this many system clock cycles are seen without hitting a previously unreached goal. 
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When this initial run-from-reset phase is finished, VCS performs a final reset then stops. 
The reset state is written to a file by VCS. If requested by the user by setting the unreach 
knob to "UNREACH_LMBM", an unreachability analysis is initiated. 

If satCycMax is > 0, CTG progresses to MODE^INTT.SAT, else MODEJNIT_SYM. 

• MODE_INIT_SAT 

In this phase, CTG uses the SAT engine to search for goals from the reset state. SAT 
uses the resource limits satCycMax and satCpuMax to know how hard to search. 

If a goal is reached, the trace is replayed in VCS followed by random simulation until 
initCycIes system clock cycles are seen without hitting a new goal. Then VCS resets and 
waits for another formal search to be carried out. 

If SAT fails to reach a goal from the reset state, then CTG progresses to the next phase. 
If symsimCycMax > 0, then MODE„INIT_SYM is entered. Otherwise CTG enters 
MODE„SAT. 

• MODE_INIT_SYM 

This phase is entirely the same as MODE_INIT_SAT, except the symbolic simulation 
search engine is used. Resource limits are defined by symsimCpuMax and 
symsimCycMax knobs. Upon a formal search miss, CTG switches to the next phase. If 
satCycMax > 0, then MODE_SAT is entered; otherwise MODE_SYMSIM is entered. 

• MODE_SAT 

In this mode VCS simulates to a deep state (as illustrated in Figure 1) and stops. This 
deep state is written to file and is used for a formal search using the SAT engine. SAT 
uses resource limits satCycMax and satCpuMax If SAT reaches a goal, the trace is 
replayed in VCS followed by more random simulation. 

In each case, VCS stops to try a formal search after rsimCycles are seen without hitting a 
unreached goal, or when a "fresh" state is seen. The definition and detection of fresh 
states are described later in this document. 

After formalMissThresh consecutive search misses, VCS is reset. If symsimCycMax > 
0, then MODE_SYMSIM_S AT is entered, else CTG stays in this phase forever. 

• MODE_SYMSIM_SAT 

This phase is similar to MODE_SAT, in that formal searches are performed from deep 
states generated by VCS. VCS stops in the same manner as that described in 
MODE_SAT. The difference is that SAT and Symbolic Simulation searches are 
alternated. When formalMissThresh consecutive formal misses are seen, the design is 
reset and CTG enters MODE.SYMSIM. 

Resource limits for the formal search engines are satCycMax, satCpuMax, 
symsimCpuMax, and symsimCycMax, 

• MODE_SYMSIM 

This phase is entirely like MODE_SAT, except that Symbolic Simulation is used instead 
of SAT. 
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• MODE_DONE 



CTG enters this phase when all goals have been classsified as either unreachable or have 
been reached. 

4.3.4. Externally Used TCL Procedures 

This section describes TCL procedures contained in hvRecipe.tcl which are intended to 
be called by the UI process directly. In addition to calling these TCL procedures, the UI 
calls many native hv commands (e.g. hvino_create_hnl_design) 

4.3.4.1 . hv_fomiaLsetup Procedure 

The hv_setup_formal TCL procedure performs various setup function needed to start a 
Slave process with intent to subsequently perform formal reachability. After initiating 
the Slave process, this procedure returns without waiting for the Slave process to 
complete setting up. Slave progress is tracked via engine messages handled in the 
various message handler routines. 

Currently supported formal engines are either SAT or Symbolic Simulation. The 
procedure prototype is the following: 

hv_setup_formal -design <desNaine> -type <rchType> \ 
-dir <v/dPath> -log <logNaine> 

This procedure starts the hv program in a Slave process, running in the directory 
specified by <wdPath>, If -log is specified, all commands issued to the Slave process 
will be logged in <IogName>. The caller must specify the design name to be analyzed, 
and the type of reachability engine to be used: either "SAT' or "SYMSIM", 

After the new channel is opened and a command stack created for it, the Dut and Goal 
Engines are started for that channel. The Sat or SymSim Engine is also started. 

The hv „dut„setup procedure is called to setup the Dut Engine, The hvjoad _soaIs 
procedure is pushed on the command stack to be called when a message is received from 
the Slave saying that the HvDsg has been created. 

If the Symbolic^imulator is being setup, the hv_start_symsim_mgr command is pushed 
on the stack to be executed after goals are loaded. 

TCL knobs used by this procedure are the following: hvPath, goalFile, covVarsFile, 
workDir (if -dir not specified), and verbMode. 

4.3.4^ hv_start_vcs_session Procedure 

This procedure is called after all formal reachability engines have been started to start the 
VCS explicit state simulator. This procedure will start performing random simulation in 
the MODE_INIT phase described earlier. After random simulation starts, this procedure 
returns. Procedure prototype is the following 

hv_start_vcs_session -exe <vcsExe> \ 

-map <mapFile> -root <rootModule> \ 
-dir <wdPath> -log <logNaine> 

This procedure starts a new channel, attaches a conunand stack to it, then executes the 
compiled VCS simulator in it (given by the path <vcsExe>), Depending on knob 
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settings and use of the -log switch, VCS may be started using a number of switches to 
that program itself. 

<rootModule> is required and is the verilog module which is being analyzed in the 
formal engines. <mapFile> is required and specifies verilog reg*s which are mapped to 
SEQ elements in the HNL, nets in verilog which are derived clocks in HNL (and 
therefore have corresponding edge detectors ), and the net that is the System Clock in 
HNL. All names in <mapFile> are valid HNL SEQ icell or inet names. 

After VCS starts, it performs one reset, it stops and waits for commands (described in a 
later section of this document). This procedure sends a $startHV PLI command to be 
processed. The hv_vcs_init_run procedure is pushed on the command stack to be called 
when $startHV finishes. After these events are initiated, hv_start_vcs_session returns 
without waiting for anything to complete. 

hv_vcs_init_run is popped from the command stack when VCS has invoked, run a reset 
sequence and stops. This is detected by a VCS_STOP message from VCS, when the 
VCS engine is in the "initing" state. 

TCL knobs used by this procedure are the following: goalFile, workDir (if -dir is not 
specified), vcsTestPile, outputVcsRchStates. 

4.3.4.3. hv_terminate_vcs_session Procedure 

This procedure may be called to terminate a test creation session prior to classification of 
all goals. By default, the test creation initiated by calling the hv_start_vcs„session 
procedure will continue until all goals have been classified. In some cases this takes a 
long time and the user may wish to terminate the process cleanly and save a testcase 
which reaches only a portion of all goals. This procedure is used for that eventuality. 
Procedure prototype is: 

hv_tenninate_vcs_session -force <forceLevel> 

This procedure sends a command to VCS to stop simulating, write out the testcase 
requested (when hv_start_vcs_session was called), and wait before exiting the VCS 
process. By default, VCS will wait until an in-process formal reach attempt has finished. 
If <forceLevei> ==1 is specified, VCS will terminate immediately without waiting. 

4.3.4.4. hv_print_ctg_knobs Procedure 

This procedure is implemented in infoFile.tcl where all TCL knobs are defined. This 
function prints out all current knobs settings. Procedure prototype is: 

hv_print_ctg_knobs -doc <docRqst> 

If <docRqst> is non-0, then a 1-line description of knob usage will be printed for each 
knob. 

4.3.5, Key Internal TCL Procedures 

This section describes in some detail TCL procedures which are used to carry out a CTG 
session initiated by the earlier externally used procedures. In general, these procedures 
are not called by the UI. 
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4.3.5.1 . hv_dut_setup Procedure 

This procedure sets up the DUT Engine in a newly-created Slave process running the hv 
program in Slave mode. Procedure prototype is the fiollowing: 

hv_dut_setup -chnl <chnlld> -design <dsgName> 

The state of the dut Engine associated with <chnlld> is set to load„hnl. The "design" 
TCL variable is set to <dsgName> in'the child process and the "hvino_create_hnLdesign' 
command is issued in the child process. This procedure returns without waiting for the 
HNL to be loaded. 

Completion of hv_dut_setup is detected via a DUT_DSG_DONE message when the 
flattened HvDsg is done being created. When completion occurs, the next conunand is 
popped off the conrunand stack. 

TCL knobs used by this procedure are the following: verbMode. 

4.3.5.2. hvJoad_goals Procedure 

This procedure is called to load goals into a newly-created Slave process running the hv 
program in Slave mode. This procedure runs after hv_dut_setup has processed the 
design. Procedure prototype is: 

hv_load„goals -chnl <chnlld> -gfile <goalFile> \ 
-var <varsFile> -style <mchStyle> 

This procedure creates a HvMch, HvSth manager, and HvOrd manager in the Slave 
associated with <chnlld>. Goals are created by sourcing <goaiFile> in that Slave. 

As part of HvMch creation, <varsFile> is sourced and expected to create an InetSet 
named "CovVars" which contains all coverage variables used in any goals. <mchStyle> 
is one of "CO WAR", "OUTPUTS", "CUTSET', or "MEM" and defines how that 
HvMch should be created in the Slave process. 

• "OUTPUTS" - Create the default HvMch, which prunes the machine 
against all Primary Outputs of the underlying HNL. This machine is 
typically used for SAT. 

• "COVVAR" - Create the HvMch using the InetSet named "CovVars" to 
prune the machine against. This machine is typically used for Symbolic 
Simulation. 

• "CUTSET^ - Create an HvMch using the InetSet names "CovVars" as the 
machine outputs, and an InetSet determined by hvcic„compute_inet_cut_set 
as the inputs to the machine. A cover (HvCic) is created using 
hvcic_create_cover_from_inet_set using the same cutset InetSet. This 
machine and cover are typically used for the Image Computation engine. 

• "MEM" - Create necessary HvMch^s for optimal Symbolic Simulation of a 
design with embedded memories. A file specified by the memlnfoFile knob 
is sourced in the child process and defines the design-specific memory 
arrays which will be optimized. 
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CTG detects that goals are done being loaded by receiving a 

HVGOL_ENGINE_WORKING message from the goal engine. Data is "DONE" and the 
goal engine must be in the "load_goalfile" state. 

This procedure uses the TCL knobs: verbMode, goalFile, cicMaxLimit, cicBlkSize, and 
memlnfoFile. 

4.3.5.3. hv_doJmbm_unreach Procedure 

Thos procedure initiates unreachability analysis using LMBM-style fixed point 
computation. Note that the underlying design may be a partition over the whole machine 
(true LMBM) or simply a single block which is a subset of the whole machine (not true 
LMBM). Procedure prototype is: 

hv„do_lrabm_unreach -init <initFile> -state <vecName>\ 
-design <desNaine> -gfile <goalFile> \ 
-gset <goalSet> -dir <wdPath> -log <logNaine> 

This procedure opens a new Channel and runs the hv program in Slave mode. The new 
program is running in directory <wdPath>. A new Command Stack is attached to the 
Channel, and Dut, Goal, and Image Engines are started for the Channel. The new 
channel uses <logName> if specified. <goalSet> specifies the name of the GoalSet 
created by sourcing <goalFile> which is to be checked for unreachable goals. 
<vecName> is the name of a StateVector created by sourcing <initFile>; this State Vector 
contains the starting state for fixed point computation. 

The following procedures are executed in order for the Channel; this is carried out by 
pushing the commands onto the Command Stack in reverse order. When each task 
subsequently finishes, the various message handlers pop the next command off the stack 
and execute it. 

• hv_dut_setup - This procedure loads HNL and creates HvDsg in the Slave 
process. 

• hv_load_goals - This procedure causes goals to be loaded into the Slave 
process. 

• hv_start_lmbm - This procedure initiates the fixed point computation in the 
Slave process. 

• hv_finish_lmbm_unreach - This procedure is called when the fixed point 
computation completes and uses the fixed point to determine which goals 
are provably unreachable. 

• hv_update^oals - Causes unreachable goals to be communicated from the 
Slave process to the Master process. The Master subsequently 
communicates the info to other Slave engines which care. 

The hv_dut_setup procedure is directly executed and this procedure returns without 
waiting for anything to finish. TCL knobs used by this procedure are: hvPath, goalFiie 
(if -gfile not used), covVarsFile, workDir (if -dir not used), verbMode. 

4.3.5A hv_startjmbm Procedure 

This procedure is called to initiate pseudo-LMBM style fixed point computation using 
symbolic state traversal techniques. This fixed point is subsequently used to prove 
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unreachable goals. This procedure is called after the DUT and Goals have been properly 
setup in the Slave process. Procedure prototype is: 

hv_start_linbm -chnl <chnlld> -init <initFile> \ 
-state <vecName> 

<chnlld> is the Channel which has had DUT created and Goals loaded properly (as 
described by previous sections). <vecName> is the name of a StateVector created by 
sourcing <initFile>; this StateVector contains the starting state for fixed point 
computation. 

Note that current usage does not really do LMBM type fixed point computation because 
the underlying machine is not partitioned into submachines. If the underlying machine 
and HvCic were partitioned, the state traversal would be true LMBM. This procedure 
issues the following commands to the Slave process without waiting for any of them to 
finish: 

• hvflc_create_cover 

• hvfml_createjib 

• hvfac_create_rpb_from_hbv„state - The starting state <vecName> is 
converted to an RPB for use by the Image Computation algorithms. 

• hvfmm_compute Jmbm - This procedure actually computes the fixed point 
The Image Engine is set to the state "run Jmbm". The resultant fixed point 
name is "lmbm_1^oint". 

The completion of this procedure is detected by receiving a IMG_ENG_LMBM„DONE 
message from the Image computation engine. A command is popped from the stack 
when this message is received. 

This procedure uses the TCL knobs: verbMode. 

4.3.5.5. hv_finishjmbm_unreach Procedure 

This procedure is called after fixed point computation has finished.. The procedure 
prototype is: 

hv_f inish_linbm_unreach -chnl <chnlld> \ 
-Imbm <lmbinNaine> -gset <goalSet> 

The Master process sends conunands to the Slave of Channel <chnlld> to cause 
unreachability computation to occur for the goals in <goalSet> using the fixed point 
<lmbmName>. 

The following commands are sent to the Slave process of <chnlld>: 

• hvfac_j)rint_rpb - This is RPB-specific information about the fixed point 
RPB named "Imbm^fjpoint". 

• hvfac_count_minterms_in_rpb - This conunand projects lmbm_fpoint onto 
the coverage variables contained in InetSet CovVars, then prints some 
statistics. 
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• hvgoLreport_unreachable - This command makes the fixed point known to 
the appropriate GoalSet. The number of Reachable, Unreachable, and 
Unknown goals are printed in a message for consumption by the Master 
process. 

At the completion of this procedure (more specifically, the resultant message from the 
hvgol_report_unreachable command), the Master process knows how many goals are 
unreachable, but not which ones. The hv_update_goals procedure describes how this task 
is completed. 

The completion of this procedure is detected by receiving a HVGOL_CMD_POP 
message with data value "report_unreach". A conmiand is popped from the stack when 
this message is received. 

This procedure uses TCL knobs: verbMode, 

4.3.5.6. hv_update_goals Procedure 

This procedure is called after a Slave process has determined unreachable goal 
information. The goals of the Master process must be updated and this procedure 
initiates the update. Procedure prototype is: 

hv_update„goals -chnl <chnlld> -gset <goalSet> 

This procedure sends a hvgoLwrite_updateJnfo command to the Slave process of 
Channel <chnlld>. The Goal Engine for that Channel is set to the *'update_goal" state 
and the procedure returns. 

The completion of the hvgoLwrite_updateJnfo conunand is detected by receiving a 
HVGOL_GOALSET_WRnE_UPD message. When this message is received, the 
update file is sourced in the Master process so that goals in the Master are correct. A 
command is then popped from the command stack and executed. 

This procedure uses TCL knobs: verbMode. 

4.3.5.7. hv_vcsJnitiaLrun Procedure 

This procedure is called when VCS has finished invoking and running its first reset 
sequence. The procedure prototype is: 

hv_vcs_initial_run -chnl <chnlld> -gfile <goalFile> 

This procedure is given the VCS Channel via <chnlld>. <goalFile> is a sequence of 
calls to the PLI routines $createSignalSetHV, $addToSignalSetHV, and 
SdefineFsmCoverHV which cause creation of goalsets which are compatible with the 
goalsets created in the formal engines. 

The following commands are sent to VCS: 

• source <goalFile> - This causes the necessary goals to be created in VCS 

• If requested, pre-reached coverage states may be loaded into VCS by calling 
the SreadCoverlnfoHV PLI routine. These pre-reached goals are identified 
by use of the inputVcsRchStates TCL knob. 
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• The SconfigStopPointHV PLI routine is called to setup stop conditioias for 
VCS, 

• The hv_vcs_stopped command is pushed onto the Command Stack for the 
VCS Channel. The VCS Engine of the Channel is set to the "running" 
state. 

• A run command is sent to VCS. This is the famous "." command. 

The procedure then returns without waiting for completion of the run command. 
Completion of the initial run is detected by a receiving a VCS_STOP message when vcs 
is in the "initing" state. Completion of non initial runs is detected by a VCS_STOP 
message while in the "stop__pending" state. 

This procedure uses TCL knobs: verbMode, goalFile, inputVcsRchStates, initCycles, 
initRunsCnt. 

4.3.5,8. hv_vcs_stopped Procedure 

This procedure is called when VCS has stopped after running biased random simulation. 
This procedure examines various pieces of information to determine what should be done 
next. Procedure prototype is: 

hv_vcs_s topped -chnl <chnlld> 

VCS has stopped running on <chnlld>. The following decision process takes place, 
depending on CTG analysis phase: 

• MODE_INIT - This is the mode where CTG is reaching as many goals as 
reasonably possible from the reset state using VCS. If the number of VCS 
runs from the reset states is less than initRunsMax, or if formal reachability 
is inhibited (using inhibitFormalReach), then 1) tell VCS to perform a reset, 
2) push hv_vcs_stopped onto the VCS command stack, 3) initiate a VCS 
run, 4) return. 

If the number of initial random runs is greater than initRunsMax then a formal 
search is initiated from the reset state. CTG analysis phase is set to 
MODE_INIT_SAT (if satCycMax is > 0), else phase is set to MODE_INIT„SYM). 
Following this phase adjustment, the following steps are taken: I) tell VCS to 
perform a reset then stop in the reset state, 2) push hv_run_formal onto the VCS 
conmiand stack, 3) tell VCS to run, 4) tell VCS to write state to a file using 
SreportDutStateHV, 5) tell VCS to write newly-reached goals to file using 
SreportNewCoverDataHV, 6) return. 

An additional decision process in this mode is to choose when unreachability 
analysis is initiated. Unreachability is launched and runs concurrently with 
reachability. Unreachability is launched from the same reset state as the first formal 
search, or earlier if unreachlnitCnt is non-0. This knob requests that the 
unreachlnitCnt-th reset state will be used to launch unreachability. If unreachability 
is launched, then the hv_do_lmbm_unreach procedure is called and VCS is told to 
write state into the file 'Imbmlnit.tcl' using the $reportDutStateHV PLI routine. 
The VCS engine state is set to *reach_lmbm_.after_reset' in order for the message 
handler to track what is going on. 
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MODE„INIT„SAT, MODE_INIT_SYM - This is the phase where CTG 
is reaching as many goals as possible using SAT/SymbolicSim from the 
reset state. VCS has stopped at some non-reset state and a formal search is 
to be setup and kicked off from the reset state. The following actions are 
taken: 1) tell VCS to perform a reset then stop in reset state, 2) push 
hv_run_formal onto the VCS command stack, 3) tell VCS to run, 4) tell 
VCS to write state to a file using SreportDutStateHV, 5) tell VCS to write 
newly-reached goals to file using SreportNewCoverDataHV, 6) return. 

MODE_SAT, MODE_SYMSIM„SAT, MODE_SYMSIM - In these 
phases, CTG is using formal searches from deep states reached using VCS. 
At this point, VCS has stopped at one of these deep states and this routine 
will either kick off a formal search, or reset VCS and try to reach more 
interesting deep states. The following actions are taken (in pseudo-code 
form): 

If { (stopped due to cycleLimit) && 

(cycleLimitMax <= cycleLimitStopCnt ) ) 

push hv_vcs_s topped onto the vcs command stack 

tell VCS to reset 

tell VCS to run 
else 

if (phase is MODE_SAT) 

push hv„run__f ormal -type SAT on VCS stack 
else if (phase is MODE_SYMSIM) 

push hv„run__f ormal -type SYM on VCS stack 

else 

if (last formal was SAT) 

push hv_run_ formal -type SYM 

else 

push hv_run_f ormal -type SAT 

endif 

endif 

tell VCS to dump state ($reportDutStateHV) 
tell VCS to dump new goals ($reportNewCoverDataHV) 
endif 



• MODE_DONE - VCS has reached all requested goals, and CTG needs to 
update the goals in the Master process then halt cleanly. The following 
* actions are taken: 1) push hv_run_formal onto the VCS command stack, 2) 
tell VCS to dump state using SreportDutStateHV, tell VCS to dump all 
recentiy reached goals using SreportNewCoverDataHV. 

When the SreportNewCoverDataHV PLI routine is issued, completion is detected by 
receipt of a VCS_NEW_WRITTEN message from VCS. A command is popped from the 
stack in response to this message. 

This procedure uses TCL knobs: verbMode, initRunsMax, inhibitFormalReach, 
updateFile, stateFile, resetConstFile, runConstFile, satCycMax, unreach, state Vector, 
goalFile, workDir, design, goalSetNames, cycleLimitMissMax. 



4.3.5.9. hv_vcs_replay„done Procedure 

This procedure is called when VCS has completed replaying a trace generated from a 
formal search engine. Procedure prototype is: 
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hv_vcs„replay„done -chnl <chnlld> -action <actType> 

<actType> specifies which action the initiator of the replay thought niight be appropriate; 
must be ^^RUN^' or "B ACK2BACK'\ 

• RUN - VCS is to run for a period of time using biased random simulation. 
The hv_vcs_stopped procedure is pushed onto the VCS command stack, 
and VCS is then told to run. 

• BACK2BACK - This action is to use "Back-to-Back" formal searches. In 
this case, random simulation is not allowed to run innumediately after a 
formal search has succeeded in hitting a new goal. hv_run_formal is 
pushed onto the VCS command stack. VCS is told to 1) write its state to 
file by SreportDutStateHV, then 2) write recently reached goals to file by 
calling SreportNewCoverDataHV 

This procedure uses the TCL knobs: verbMode, updateFile, stateFile, resetConstFile. 

4.3.5.10. hv_start_symsjnn_mgr Procedure 

This procedure is called to setup the Symbolic Simulation manager prior to performing 
any searches using that engine. This procedure is called once at the beginning of a 
session, after goal and dut engines are properly set up, Ord, Sth, and Mch are already 
built, etc. Typically called from hv„setup_formal. Prototype is: 

hv_start_symsiin_ingr -chnl <chnlld> 

<chnlld> is the channel that should have a Symbolic Simulation manager built. The 
hvprm_sim_manager create command is called in the child process. It is expected that 
hvmch_$design, hvflc_$design, and hvord_$design are valid Mch, Flc, and Ord objects, 
respectively. 

Completion of this sequence is detected by receipt of HVSYM_MGR_SETUP message. 
A command is popped from the command stack in response to this message. 

4.3.5.11. hv_runJormal Procedure 

This procedure is called to initiate a formal search on a properly opened and set up 
Channel. Function prototype is: 

hv_run_formal -chnl <chnlld> -sfile <startFile> \ 
-update <updateFile> -const <constFile> 
-type <rchType> 

<rchType> must be "SAT' or "SYMSIM", depending on which engine should be used 
for the formal search. <startFile> is a TCL file to be sourced in the Slave process to 
create a StateVector; this StateVector defines the starting state for the search engine. 
<updateFile> is a TCL file to be sourced in the Slave and Master processes to update the 
GoalMgr with states reached by VCS since the last <updateFile> was generated. 
<constFile> is a TCL file to be sourced in the Slave process to cause the search engine to 
see certain primary inputs as of a constant value. Note: This <constFile> is expected to 
be obsoleted when HNL-based environmental modeling can specify the same data. 

Actions carried out in this procedure are: 
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1 . Issue commands to all Slave processes running symsim or sat engines to 
**source <updateFile>'\ This causes all processes to have full knowledge of 
what goals have been reached by VCS. 

2. Push hv_formaLstopped onto the Command Stack of the channel to 
perform the formal search. 

3. If we are initiating back-to-back searches, adjust resource limits 
accordingly. If <rchType> is "SAT, iteration limit is set to satB2BCycMax 
or satCycMax. If <rchType> is "SYMSIM", iteration limit is set to 
symsimB2BCycMax or symsimCycMax. 

4. If <rchType> is SYMSIM, source <constFile> in the child process, then 
source $S YNOPSYS/auxx/ctg/tcl/runPrm.tcl in the Slave. If <rchType> is 
SAT, then call the hvcnf_sat command in the child process. 

5. The procedure then returns. 

Completion of the formal search is detected by receipt of either HVS YM_SIM_DONE or 
HVSAT_REACH_DONE messages. A conmiand is popped from the command stack in 
response to either of these messages. 

This procedure uses the following TCL knobs: symsimCpuMax, symsimCycMax, 
symsimB2BCycMax, satCpuMax, satCycMax, satB2BCycMax, goalSetNames, 

4.3.5.12. hv_formaLstopped Procedure 

This procedure is called when a formal search engine has terminated a search. The 
search may have terminated after finding one or more goals, or it may have terminated 
after exceeding some user-provided resource limits. Procedure prototype is: 

hv_formal_s topped -chnl <chnlld> -type <rchTYpe> 

<rchType> is either "SAT' or "SYMSIM" and is the type of search engine which was 
initiated on the Channel of <chnlld>. 

Note that when the search engine completed, it reported how many goals were found; this 
data recorded in either satHandler.tcl or symsimHandler.tcl. 

The decision process of this routine is outlined by the following pseudo-code. 

If (phase is MODE_INIT_SYM) 

If (search found 0 goals) 
If (satCycMax>0) 

Set phase to MODE_SAT 

Else 

Set phase to MODE^SYMSIM 

Endif 

Set non-init -phase VCS stop conditions \ 

& freshness using $conf igStopPointHV 
push hv_vcs_s topped on VCS cmd stack 
set VCS engine state to ''running" 
tell VCS to run 

Else 

Push hv__vcs_replay_done on VCS cmd stack 
Tell VCS to bias weights 
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Tell VCS to replay a trace 

Set VCS engine state to ''running" 

Tell VCS to run (do the replay) 

Endif 

El self (phase is MODE_INIT_SAT) 
If (search found 0 goals) 
I f ( syms imCycMax> 0 ) 

set phase MODE_INIT„SYM 

Else 

set phase MODE_SAT 

Endif 

If (phase is MODE_INIT_SYM) 
Call hv_run_f ormal 

Else 

Set non-init-phase VCS stop conditions \ 

& freshness using $conf igStopPointHV 
push hv„vcs_s topped on VCS cmd stack 
set VCS engine state to "running" 
tell VCS to run 

Else 

Push hv_vcs_replay_done on VCS cmd stack 

Tell VCS to bias weights 

Tell VCS to replay a trace 

Set VCS engine state to "running" 

Tell VCS to run (do the replay) 

Endif 

Elseif (phase is MODE„SAT, MODE„SYMSIM„SAT, MODE_SYMSIM) 
If (search found 0 goals) 

If (phase is MODE_SAT) 

If (syinsimCycMax>0) 

set phase MODE_SYMSIM„SAT 

Endif 

Elseif (phase is MODE_SYMSIM„SAT) 
If (lastFormalEng was SAT) 

Set phase to MODE_SYMSIM 

Endif 

If (#consecMisses > f ormalMissThresh) 
Push hv„vcs„stopped on VCS stack 
Set #consecMisses to 0 
Tell VCS to reset 

Elseif (lastFormalEng was SYMSIM) 

Push hv_vcs_replay_done on VCS stack 
Tell VCS not to bias weights 
Tell VCS to replay a trace 

Else 

Push hv_vcs_s topped on VCS stack 

Endif 

Else 

If (tconsecHits > f ormalClearThresh) 
Tell VCS to clear bias weights 

Endif 

If (back2back enabled) 

Push hv_vcs_replay_„done on VCS stack \ 
(with BACK2BACK action) 

Else 

Push hv_vcs_replay_done on VCS stack \ 



(with RUN action) 

Endif 

Tell VCS to bias weights 
Tell VCS to replay 

Endif 

Set VCS engine state to "'running" 
Tell VCS to run 

Endif 

This procedure uses the following TCL knobs: verbMode, satCycMax, symsimCycMax, 
freshStartFrac, fxeshSampFrac, rsimCycles, freshSuppress, updateFile, stateFile, 
resetConstFile, formalMissThresh. formalClearThresh, backToBackEnabled. 

4.3.5.13. hv_update_cover_metric Procedure 

This procedure computes the actual cover metric used to determine progress made in the 
overall coverage session. This is a function of all goals/goalsets currently defined. Sets 
the covMetric TQL variable. Procedure prototype is: 

hv_upda t e_co ver_ine trie 

This procedure takes no arguments. 

4.3.6. TCL Knobs and Variables 

The CTG control mechanisms, heuristics, and decision algorithms are largely 
implemented in TCL code running in the Master process. This TCL code allows for 
many user-specifiable configuration settings; these are called TCL "knobs". This control 
TCL code also needs to keep track of session progress and status; this makes use of TCL 
"variables" which change as the session progresses. 

The TCL language is limited in variable scope and data types. Variables are visible 
either globally or local to a single procedure. Global variables used in a procedure must 
be declared in that procedure as 'global' before use in the procedure. TCL variables must 
be of type string or array; array variables are indexed by strings and are one-dimensional. 

All TCL knobs and variables are organized as elements of a single global array variable 
named "ctglnfo". The previously mentioned knob "satCycMax", for example, is actually 
referenced as "ctgInfo(satCycMax)". When a TCL knob or global variable is added to 
the ctglnfo array, a documentation entry is also entered in a corresponding array 
"ctglnfoDoc". The documentation line for ctglnfo(satCycMax) is thus contained in 
ctglnfoDoc(satCycMax) and its value is: "Maximum SAT cycles allowed per search". A 
TCL procedure hv_print_ctg_knobs is provided to print knob values and documentation; 
this procedure was described earlier. 

This remainder of this section documents knobs and variables in use at the time of 
writing this document. 

4.3.6.1. TCL Knobs 

The following knobs are used to configure the CTG TCL control code. In each case, the 
knob name is provided without the "ctglnfoO" for clarity. Knob default values are also 
provided, where relevant. 

• workDir - Directory that child process are started in, by default. 
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stateFile "stateFile.tcl" - Name of temporary file VCS uses to write current 
design state into. When sourced. a State Vector is created then each state 
element is set to the current value (0/1) in the VCS simulation session. 

state Vector "StateVec" - Name of State Vector that updateFile.tcl saves 
state in when it is sourced 

updateFile "updateFilctcl'* - Name of temporary file VCS uses to store 
reached states in when this info is shared with otiier processes. When 
sourced, all goals and goalsets are updated with goals which have been 
reached since the last time VCS was asked to report newly reached states. 

runConstFile *'<no„consts>" - Name of file which can be sourced to set 
certain signals to constant values suring symbolic simulation. This file 
consists of a series of hvprm_input_set_to_constant commands 

resetConstFile "<no_consts>*' - Set certain signals to constant values for 
Symbolic Simulation from the reset state. Similar to runConstFile, except 
used only when simulating from reset state, 

goalFile "goalFile" - Basename of files used to create goals in hv and VCS 
child processes. It is expected that <goalFile>.vlog can be sourced in VCS, 
and <goalFile>.tcl can be sourced in hv. 

goalSetNames "<no_goalsets>" - Space-delimited list of GoalSet names 
which are created by sourcing the above <goalFile>. 

goalNaraes "<no_goals>" - Space-delimited list of Goal names which are 
created by sourcing the above <goalFile>. 

covVarsFile "covVars.tcl" - Name of file to source in hv which creates an 
InetSet named XTovVars', This InetSet contains all coverage variables used 
in all goals and goalsets analyzed in this session. 

unreach "UNREACH_NONE" - Knob which specifies style of 
unreachability analysis to perform. Valid values are: 

• UNREACH_NONE: No unreachability used 

• UNREACH_LMBM: Use Imbm-type fixed point computation 

unreachlnitCnt 3 - Specify which reset state should be used to initiate 
unreachability from. In practice, not all verilog registers in a design are set 
to a specific value by the reset sequence. Thus, sometimes X logic values 
may take many simulation cycles and/or resets to flush from the system. In 
these cases, the furst reset state generated may not be a good start-point for 
unreachability analysis. This knob specifies that the i-(Ji reset state should 
be used for unreachability computations, Unreachability will start no later 
than when the first formal search is initiated. I.E. when MODE_INTr is 
exited. 

inhibitFormalReach 0 - If this knob is non-0, then formal search 
mechanisms are not used. CTG stays in MODE_INIT forever. 



verbMode 1 - Specifies verbosity mode to use in TCL control code running 
in the Master process. Set to one of: 

• ctglnfo(verbUSER): Not much verbosity 

• ctglnfo(verbAPPLICATION): a little more 

• ctglnfo(verbDEVELOPMENT): still more 

• ctglnfoDoc(verbPANIC): so much we get lost 

freshMode "START„FRESH_OFF" - This knob specifies when freshness 
detection should start to be used. Valid values are: 

• START_FRESH_OFF: dont use freshness. 

• START_FRESH_DYNAMIC: use freshness after the first miss 

• START_FRESH_ALWAYS: freshness on from the very start 

freshSuppress 3000 - Number of cycles to suppress freshness detection at 
the beginning of a random simulation run 

fresfaSampFrac 1000 - Sample fraction, in 1/1000 percent units, to use for 
fireshness detection. If a given state has been seen less than this percentage, 
then that state is said to be "fresh". 

freshStartFrac 10000 - Start fraction used for freshness detection. When 
VCS is asked to save current state to a file, this is taken to be a start point 
for a formal search. If a given state has been used as start point less than 
this percentage of all times a start has been initiated, then the state is said to 
be fresh. 

cicBlkSize 50 - The size of blocks to use for HvCic object used for 
unreachability analysis. 

cicMaxLimit 3000 - The maximum number of latches to use in the HvCic 
object used for unreachability analysis. 

rsimCycIes 10000 - The number of clock cycles VCS will perform random 
simulation before stopping for direction. VCS runs this many clock cycles 
past the time the last new state (i.e. goal) was reached. The TCL control 
code in the Master process then determines if the current state should be 
used for formal search, if a reset should occur, etc. 

initCycIes 2000 - The number of clock cycles of random simulation to 
perform after a reset sequence. VCS will run this many cycles past the last 
new state (i.e. goal) seen 

initRunsMax 2 - How many sequences of Reset+RandomSim will be 
performed before CTG exits MODE_INIT 



dynamicBiasCycles 1000 - How many cycles of dynamically biased 
random simulation will be run after a successful formal search to hit a new 
goal. After this many cycles, user-biased random simulation will be used. 

satCpuMax 600 - Maximum number of CPU seconds which is allowed for 
a formal search using SAT. 

satCycMax 50 - Maximum number of simulation steps (i.e. clocks) which 
are allowed for a SAT formal seach 

satB2BCycMax 10 - Maximum number of simulation steps allowed for a 
SAT search when used as the second search in a BackToBack search. 
Generally this number is less than satCycMax. 

symsimCpuMax 600 - Maximum number of CPU seconds which is 
allowed for a formal search using Symbolic Simulation. 

symsimCycMax 50 - Maximum number of simulation steps (i.e. clocks) 
which are allowed for a Symbolic Simulation formal seach 

symsiinB2BCycMax 25 - Maximum number of simulation steps allowed 
for a Symbolic Simulation search when used as the second search in a 
BackToBack search. Generally this number is less than symsimCycMax. 

formalReplayFile "prm_sequence" - Name of temporary file used by 
formal search engines to save replay traces in. This file is then read by 
y CS to replay the trace 

cycleLimitMissMax 2 - This knob specifies how many times a formal 
search may be initiated from a non-fresh state when a miss occurs. The idea 
is that often a search from non-fresh state has no hope of succeeding. Note 
that these seaches occur when rsimCycles of simulation have occurred in 
VCS since that last goal was hit. 

backXoBackEnabled "OFF' - This knob specifies if BackToBack should 
be enabled or not Values of OFF and ON are allowed. BackToBack 
causes a formal search to be performed immediately after a formal search 
has succeeded in hitting a new goal. The default behavior is to perform 
dynamically biased random simulation from these points. 

formalMissThresh 2 - Number of consecutive formal searches which may 
fail before VCS is instructed to perform a reset. 

formalClearThresh 3 - Number of consecutive formal searches which may 
succeed before dynamic biasing weights are cleared in VCS. 

vcsTestFile '*<no_testfiie>" - Name of file which the generated test is to be 
saved in. This test may be used later as a stand-alone regression test in 
VCS. Two files are saved: 

• <testFile>.ctg contains the control program to reproduce the input 
stimulus. 

• <testFile>.vgol specifies the goals and goalsets used for the test. 



• inputVcsRchStates "<noJnputfile>" - This file specifies goals which are 
considered to have been previously reached. These goals are classified as 
"reached" at the beginning of the CTG session, and no attempt is made to 
generate a trace to these goals. 

• outputVcsRchSta tes - This file specifies a file to record goals which are 
reached during this analysis session. This file format is suitable as input to 
later CTG sessions. 

4.3.6.2. Variable Usage 

This section lists glaobal variables used by multiple TCL procedures in the TCL control 
code running in the Master process. 

• ctgMode - This variable contains which phase CTG is currently in. One of 
MODE„INIT, MODE_INIT_SAT, MODE_INIT_SYM, MODE_SAT, 
MODE_S YMSIM_S AT, MODE_S YMSM, or MODE„DONE 

• unreachStarted - Variable that says unreachability has been started (if non- 
0) 

• initRunsCnt - Number of MODE_INIT simulation runs which have been 
performed from the reset state. 

• covMetric - This variable is the number of goals left to be classified 

• formalMissCnt - Number of consecutive formal search misses seen. 

• formalHitCnt - Number of consecutive formal search hits seen. 

• formalTraceCnt - How many goals the last formal search found 

• lastReachType - Which type formal search engine was used last 

• back2BackInProcess - A BackToBack search is in progress 

• lastVcsStopReason "<no_reason>" - Reason that the 1st VCS simulation 
stopped. One of VCS_STOP_UNKNOWN, VCS_STOP_DONE, 
VCS_STOP_CYCLE_LIMIT, VCS_STOP_FRESH, 
VCS_STOP_END_REPLAY 

• cycleLimitMissCnt - How many formal search misses have when seen 
when atcycle limit stop point. 

• hvPath "/vobs/propver/src/hv/bin-gccsparcOS5/hv-g" - Pathname to where 
hv executable lives 

4.3.6.3. ctgVcsCoyerObis Variable 

When a coverage object is created in VCS(e.g. creating a GoalSet by using the 
SdefineFsmCoverHV PLI routine), it is given a unique "handle". This handle is then 
used as input to other PLI routines during the CTG session. The same coverage object is 
known by name in the Master process and other hv Slave process. The ctgVcsCoverObjs 
variable is an array that maps a coverage object name (e.g. the GoalSet name) to its 
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corresponding handle in the VCS process. For example: ctgVcsCoverObjs(GoalSetl) = 
1. 

4.3.6.4. ctgVcsCoverStatus Variable 

The CtgVcsCoverStatus variable is an array which records current classification counts 
for the goals which correspond to a coverage object in VCS. Index into the array is the 
VCS handle of the object. Data value is a string of 3 space-delimited numbers: 
ctgVcsCoverStatus(l) = **#unknown #unreachable #reached". 

The creation, maintenance, and use of goals is central to the CTG methodology. Goals are, after all, what 
are being "covered", "reached", "proven", "classified", etc. The hv program provides a number of goal- 
related TCL commands which are documented in this section. In addition, the PLl code linked into VCS 
provides certain goal-related capabilities which are discussed. 

5.1. Introduction 

In general, each of the Slave processes in use in the CTG system will need some or all of 
the goal information collected by the other Slave processes. The TCL control code 
running in the Master process is responsible for updating the necessary goal information 
in a Slave process before asking for an analysis by that Slave. 

Note that in many cases a Slave does not need all accumulated goal information before 
carrying out its portion of the CTG session. For example, unreachability analysis 
performed by LMBM fixed point computation has no need to know that some goals have 
already been reached. 

At all times, the Master process is the central keeper of the union of all goal results 
determined by all child processes. The Master process TCL code is responsible for 
propagating all generated results from Slaves to the Master, and from the Master to 
Slaves that need the information. 

5-2. HvGol Package TCL Commands 

The HvGol package provides the following TCL commands which are used to manage 
goal information within the CTG system. Note that not all hvgoL* commands are used 
currently by CTG. Only those commands in use or otherwise of interest are mentioned 
here. 

• hvgol_create_goaI - This command creates a goal from a single signal or 
an HbvState Vector. The goal is given a name at creation time. 

• hvgol_create_goalset - This command creates a goalset given an InetSet 
which contains the coverage variables of interest. Given N coverage signals 
whichmay take binary logic value B={ 0,1}, then 2 **N goals are implied 
by the GoalSet and have all logic values given as B**N. 

• hvgol_goalset_add_info — This command is used to incrementally specify 
reached/unreachable state information for an existing GoalSet. Unreachable 
states must be represented as either fixed point HvRpb or as a HvHbv 
State Vector. Reached states are specified as HvHbv State Vector . 
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• hvgol_goalset_relations - This command copies out some or all of tlie 
HvSth_Relation_t's which are used internally to represent the Unknown, 
Unreachable, and Reached goals of the GoalSet. The user provides the 
names used to create named HvMgr instances of type HvSth_Relation_t. 

• hvgoLwrite_update„info - This command writes into a file the 
HvSth„Relation_t objects which represent the unknown, unreachable, and 
reached relations for a given GoalSet. This information is suitable for 
reading in using the hvgol_read_update„info conrmiand. 

• hvgoLread_updateJnfo - This command reads goalset information written 
by one hv session, and used in another. The provided reached, unreachable, 
and unknown Relations from one goalset are used to update the same 
GoalSet with new information. 

• hvgol_report_goal - This command reports various information about a 
Goal. 

• hvgoLreport_goalset - This command reports various information about a 
GoalSet 

• hvgoI_report_unreachable — This command reports reached/unreachable 
state information to a goal or goalset. This command is somewhat mis- 
named, as the semantics are that the caller is reporting to the Goal, rather 
than vice- versa. Unreachable states are in RPB fixed point form. 
Unreachable states are specified as an HvHbv StateVector. 

5.3. HvPIi Services For VCS Usage 

Certain goal capabilities are implemented in the VCS Slave process using standard PLl 
capabilities. VCS is invoked in interactive mode so that these PLI routines may be 
"called" by the Master process. The PLI routines provided for goal creation/maintenance 
are the following: 

createSignalSetHV PLI Routine 

$createSignalSetHV( "<setName>*' ) 

This PLI routine is used to define a Signal Set in the VCS process. A SignalSet is entirely 
analogous to an InetSet in one of the hv proceses. The "setName" argument is a string 
that is expected to correspond to a InetSet in the Master process. 

addToSignalSetHV PLI Routine 

$addToSignalSetHV( "<setName>" , <signal>, "<addMode>" ) 

This PLI routine is used to add a Verilog signal to the named SignalSet. <signal> may 
be either a net or register in verilog. <addMode> is a string that is either PRE or POST to 
indicate the signal should be prepended or appended to the SignalSet. The order of the 
signal in the SignalSet is expected to be the same as the order of signals in the 
corresponding InetSet. 

reportSignalSetHV PLI Routine 

$reportSignalSetHV( "<setName>" , " <f ileNaine> " , "<fmt>*') 



5.3.1. 



5,3.2, 



5.3.3. 
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This PLI routine writes a SignalSet given by <setName> out to <fileName> in a specified 
<format>. <format> is a string that is either "HV" or "PLI". These formats are suitable 
to be sourced in either hv or VCS programs to reconstruct the SignalSet. 

5.3.4. defineFsmCoverHV PLI Routine 

$def ineFsmCoverHV{ "<objName>" , "<signalSetName> " , \ 
<sysClk>, <offSet>, <f sinHandle>) 

This PLI routine creates an Fsm type coverage object named <objName>. The goals are 
defined as all [1,0] combinations of the signals contained in <signalSetName>. If there 
are N signals in SignalSet, then 2**N individual goals are defined with this conamand. 
These signals are sampled relative to the positive edge of the clock signal <sysClk>. 
<offSet> specifies a non-negative offset by which the sample time can be adjusted so that 
the sample happens a short time after the positive edge of <sysClk>. This routine 
allocates a unique positive integer handle for the coverage object; this is returned as 
<fsniHandle>. 

5.3.5. defineBitloggleCoverHV PLI Routine 

$defineBitToggleCoverHV("<objNaine>" , "<signalSetNaine> " , \ 
<sysClk>, <offSet>, <f sinHandle>) 

This PLI routine creates a Toggle coverage object named <objName>. Signals given by 
the <signalSetName> are to be toggled to both 1 and 0; these are the goals. If there are N 
signals in SignalSet, then 2*N individual goals are defined vwth this conunand. These 
signals are sampled relative to the positive edge of the clock signal <sysClk>, <offSet> 
specifies a non-negative offset by which the sample time can be adjusted so that the 
sample happens a short time after the positive edge of <sysClk>. This routine allocates a 
unique positive integer handle for the coverage object; this is returned as <fsmHandle>. 

5.3.6. getCoverMetiicHV PLI Routine 

$getCoverMetricHV(<covHandle>, <covN\iinber>) 

This routine determines how many goals remain unclassified in the coverage object 
identified with <covHandle>. If <covHandle> is -1, then all currently-defined coverage 
objects are used and the returned <covNmuber> is the summation of sdl unclassified 
goals, 

5.3.7. reportNewCoverDataHV PLI Routine 

$reportNevyK:overDataHV(<covHandle>, "<f ileNaine> " ) 

This PLI routine writes to <fiIeName> all goals which have been covered since the last 
call to this routine. <fileName> must be writeable, and will be overwritten by this 
routine. The output file is expected to be sourced by the hv program to update the 
corresponding GoalSets in the hv process. File contents are tfie following: 

• create a StateVector v^th the same name as the GoalSet (hvhbv_new_vector 
-init DC.) 

• Set each care bit in the StateVector using hvhbv_set_vector_bit 

• Update the GoalSet using hvgol_goalset_add_info to present the properly 
loaded StateVector as a new reached state for the GoalSet. 
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5.3.8. inform UnreachCountHV PLI Routine 

$ inf ormUnreachCountHV ( <covHandle> , < #unr each> ) 

This PLI routine is used to inform the PLI code that a certain number of states of the 
given coverage object have been proven unreachable. The effect of this routine is to 
adjust the coverage metric for the coverage object given by the handle <covHandle>. 
Note that this command is additive for a given coverage object; this allows for 
unreachable goals to be proven throughout an analysis session by different unreachability 
algorithms. 

5.3.9. printCoverlnfoHV PLI Routine 

$printCoverInf oHV<<covHandle>, "<f ileNaine>" , "<fmt>") 

This PLI routine writes out reached state coverage information out to the file named 
<fileName>; this file must be writeable and will be overwritten. If <covHandle> is -1, 
then all current coverage objects are written, else the one specified by the handle 
<covHandle>. <format> is a string and is one of "COMPACT', "COMPACT_REACH", 
or "HUMAN''. "COMPACT" and "COMPACT_REACH" formats are intended to be 
readable using the $readCoverInfoHV PLI routine. "COMPACT' simply writes out the 
cover object name and coverage signals. COMPACT_REACH writes cover object name, 
coverage signals, and reached states. "HUMAN" writes information out in a human- 
readable form. 

5.3.10. readCoverlnfoHV PU Routine 

$readCoverInf oHV( ileName> " , <use_rch>) 

This PLI routine reads coverage object definitions from the file given by <fileName>. 
<use_rch> is an integer; if non-0, then any reached states contained in <fileName> are 
taken to be previously-reached states and are immediately considered as reached. The 
next call to SreportNewCoverDataHV will report these states as reached. 

5.4. Usage Scenarios 

When goals are determined to either be unreachable or reached, this information must be 
communicated to other parts of CTG which need this information. This section 
describes these system-level interactions. 

Unreachable State Computation 

When unreachability analysis has been completed by one of the Slave processes, the 
unreachable state data must be reported to the Master process, and conveyed to the VCS 
process so that the coverage metric can be adjusted properly. The Slave process is told to 
write unreachable states to file using the hvgol_write_update_info. The Master process 
then uses the hvgol_read_update_info conmiand to update its central copy of the GoalSet 
information. The number of unreachable states is reported to the VCS Slave by calling 
the SinformUnreachCountHV PLI routine. 

If a SAT solver is active, then the unreachable states are also read into that process. 
Reached State Information 

The CTG system does not consider a Goal to have been reached until VCS has generated 
an input sequence that actually reaches a state which covers the Goal. When a Goal has 
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been reached, then this information must be conveyed to the Master process, as well as 
any Slave processes which can take advantage of this information. 

This update process occurs each time VCS stops simulation and waits for input directive 
from the Master process. The following actions then occur: 

• VCS is told to write out newly reached goals using the 
SreportNewCoverDataHV PLI routine. 

• The Master process updates its copy of the GoalSet by sourcing the file of 
update information. As previously described, this file creates a vector of 
Don't-Care bits then sets all care bits to the appropriate value. This 
StateVector is then used with the hvgol^oalset_add Jnfo command. 

• All Slaves used for reachability analysis are also told to source the update 
file. 

The User Interface of Figure 2 interacts with the core CTG system via the Master process. As previously 
described, conmiands are issued to the Master process via a unix pipe which feeds stdin of the Master 
process. All native hv commands, as well as the externally usable TCL control routines in hvRecipe.tcl, are 
available for UI needs. This interface allows the UI to be written in either Graphic or Textual modes 
without any changes, from the Master process perspective. Refer to some other Ul-specific document for 
detailed issues about User-level interactions with CTG. 




As indicated earlier, the explicit state simulation engine integrated into CTG is based on VCS. CTG 
capabilities are linked into VCS directly via PLI techniques for direct simulation access, and using VERA 
mechanisms for testbench control, constraints, and biasing. 

For detailed descriptions of VERA coding and compilation issues for use with CTG, refer to appropriate 
CTG VERA documentation. This section describes the specific control & interface mechanisms for CTG 
interactions with VERA code. 

For more detailed VCS and PLI descriptions, refer to appropriate product literature. This section document 
CTG interfacing and control mechanisms present in the VCS Slave process. 

7.1 . PLI Interfacing - hvPII 

As part of a product deliverable, CTG provides PLI routines embodied in a precompiled 
hvPli.a archive library which is linked to the VCS compiled simulator. A hvPli.tab 
interface file is provided so that these PLI routines can be called from the user PLI code, 
as well as interactively from the VCS interactive command line. 

PLI routines used in the CTG product are the following. Note that Goal-specific PLI 
routines were described earlier in this document and are not repeated here. 

7.1.1. startHV PLI Routine 

$startHV(<rootInst>, "<inode>" , "<regMapFile> " , \ 
"<inGoalFile>'' . "<outGoalFile> " ) 
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This PLI routine is called at the very start of a CTG session to properly setup and 
initialize the CTG PLI mechanisms. This routine is called either by the Master process 
when creating a testcase, or by theCoverBooster program when replaying a previously- 
created testcase. 

<rootInst> is a module in the verilog netlist which is being formally analyzed. 

<mode> specifies whether a test is being created ("SLAVE_CREATE") or a previously- 
created test is being replayed ("FREE_REPLAY"). 

<regMapFiIe> is a file which specifies the HNL name of sequential elements in the 
formally-analyzed design. These names are decoded, together with <rootInst>, to 
identify registers in the verilog which comprise "state" of the Design Under Test. This 
information is especially relevant to the $reportDutStateHV PLI routine. Only registers 
which are relevant to the HNL model (i.e. those verilog registers "inferenced" as 
sequential elements by the synthesis process) are reported as DUT state for use as start 
point of formal searches. <regMapFile> is required for mode "SLAVE_CREATE" and is 
not required for *'FREE_REPLAY". 

<goalFile> specifies SignalSet and coverage objects. This file may be omitted, but no 
coverage can be measured until cover objects are defined. As discussed earlier, other PLI 
routines are provided to define coverage objects after this point. 

<outGoalFile> is optional and is used to specify a file which reached goals will be saved 
in upon VCS termination. This format is suitable to be used as input <goalFile> or as 
input to the $readCoverInfoHV routine. 

7.1 .2. reportDutStateHV PLI Routine 

$reportDutStateHV( "<outFile>" , "<Xmode>" ) ; 

This routine writes the current state of the DUT out to file <outFile>. The file format is 
intended to be sourced by the hv program; a HvHbv StateVcctor named "StateVec" is 
created for the machine named "hvmch_$design". Each bit of StateVec is assigned the 
current logic value of the corresponding verilog register. Only registers indicated by the 
<mapFile> of $startHV are assigned values. The <Xmode> parameter is a string which 
indicates what logic value should be used for registers which currently have the logic X 
value. If <Xmode> is **DC", then those X-ed registers have Don't Care value; if 
<Xmode> is XONST", then those X-ed registers will be assigned logic 0 value. 

When a register is encountered in the X state, a message is printed (maximum of one 
message), A comment is written at the end of <outFile> which documents how many 
registers were in the X state. 

7.1 .3. InformSearchResultsHV PLI Routine 

$informSearcliResultsHV{<#reached__goals>) 

This PLI routine is used to tell the VCS-resident hv code that the previous search was 
either successful or not This information is used to determine applicability of a 
particular state for use as a future search start point. For example, if a particular state was 
used as the start state for a formal search, and that search failed after 2 hours, then the 
state might not be a good point to stop and search from in the future. 

The <#reachedGoals> is how many goals were reached by a formal search engine firom 
the state last used by the last call to $reportDutStateHV. 
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7.1.4, configStopPointHV PLI Routine 

$conf igStopPointH ( <tr igReg> , <covHandle> , \ 

<samplePercent> , <startPercent> , <cycCnt> , <suppCnt> ) 

This PLI routine is used to tell the VCS-resident HV a simulatiton run should pause and 
' allow control decisions to be considered by the Master process, 

<trigReg> is a verilog wire which will be toggled when a "good" stop point has been 
reached. If <trigReg> is null, then the PLI routine tf_dostop() is called. 

<covHandle> specifies the coverage object to which this stop configuration applies. If 
<covHandle> is -1, then this information applies to all current coverage objects. 

<samplePercent> is an integer, in 1/1000 percent units, which specifies an upper bound 
for how often a state can be "visited" and still be considered "fresh". For example, if a 
coverage object has been sampled 1000 times and has been in a given state S 10 of those 
1000 times, then S has been visited 10/1000 or 1% of the total sample times. If 
<samplePercent> is greater than 10, then S is considered fresh and may cause a 
simulation stop to occur. Note that "state" consists of only the coverage variables used 
by the coverage object; not all registers of the design. 

<startPercent> is an integer, in 1/1000 percent units, which specifies an upper bound for 
how often a state may be used as a "start state" for formal searches. Each state at the 
time SreportDutStateHV is called is considered a "start state" for a formal search. 

Note: it is acknowledged that this is not quite always true. However, in the current 
system, this is very nearly a true statement. 

As an example, if a state S has been used for start state 3 times, and 30 formal searches 
have been performed, then <startPercent> must be greater than 100 (10%) in order for S 
to be considered "fresh". A special case happens if a previous search from state S 
resulted in no goal reached; in this case, S will never be used again as a stop point 

<cycCnt> specifies a maximum number samples which are allowed to pass until a stop is 
called. This limit is relative to the last goal reached in the coverage object, or relative to 
the last reset sequence being executed. If <cycCnt> is 0, then a stop will only occur for 
fresh states. 

<suppCnt> is a freshness "suppress" count. Freshness detection is suppressed for this 
many samples after a new goal is reached. 

Note that if either percent is 0, then that metric is turned off for freshness detection. If 
both percentages are non-0, then a trigger (i.e. stop) condition is the AND of both 
percentages. 

7-2. Verilog TestBench Top Module 

The verilog testbench top file is generated by the vera synthesis tool. This *top.v" file 
instantiates the verilog module being verified, as well as VERA constraint and biasing 
mechanisms. Refer to appropriate documentation for more details on this process. This 
section discusses control and interface aspects contain in the top module. 

Verilog Control and Status Variables 

As outlined earlier in this document, the TCL control code running in the Master process 
needs to tell the VCS Slave to do a number of things. For example, ^'execute a reset 
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sequence", "replay a generated trace", "clear dynamically-biased weights", etc. The 
mechanisms used to convey these commands are to 1) call various CTG-supplied PLI 
routines, or 2) set various control flags in the verilog testbench top. These control flags 
are periodically checked by the VERA VCS code which controls the VCS Slave process. 
This VERA control code is called "CoverBooster" and is described in a later section of 
this document. 

Flags are defined as verilog "reg"s, and are set to 1 or 0 interactively by using the native 
VCS command "set". For example, given a statement: 

reg foe- 
Then the following interactive VCS conunand will set foo to 1 . 

cli_l> set foo=l 
Control flags which are used in the top module of the verilog testbench are the following: 

• hvResetFlag - This flag is used to tell CoverBooster to apply the reset 
sequence at the next possible time. This calls the reset() task in the 
design_interface implemented in VERA code. This flag is initialized to 1 
so that a reset is performed as the very first action, 

• hvReplayTraceFlag - This flag tells CoverBooster to replay a replay trace 
generated by one of the formal search engines. The filename used to 
contain the trace is defined historically as "prm_sequence". This flag is 
initialized to 0. 

• hvClearWeightsFlag - This flag tells CoverBooster to clear dynamically- 
biased input wieghts. This calls the reset_weight() task in the 
dynamic_interface implemented in VERA code. This flag is initialized to 0. 

• hvStopFlag - This flag causes CoverBooster to call the VCS $stop() 
routine. This flag is initialized to 1, so that CoverBooster stops after 
applying the first reset sequence; the Master process then calls $startHV and 
the actual CTG session can be started. 

• hvQuitFlag - This flag causes CoverBooster to exit the main command loop 
and write out a repeatable test file. VCS then executes the Sstop command 
and waits for further input. The CTG test generation process may not be 
continued from this point. This flag is initialized to 0, 

• hvBiasWeightsFlag ™ This flag causes CoverBooster to use information in 
the next replayed trace to modify primary input weighting information. This 
flag is initialized to 0, 

Vera-Accessible PLI Tasks 

The CoverBooster program needs access to many of the PLI routines and verilog flags 
maintained in the verilog testbench top file. The mechanisms VERA uses for this is via 
verilog "tasks" which are implemented in top and declared external for CoverBooster in 
an include file. This section describes those VERA-accesible tasks: 

• The startHV task calls the $startHV PLI routine and is used by 
CoverBooster when replaying a previously-generated testcase in stand- 
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alone mode. More detail on this mode is given in a later section of this 
document. This task prototype is the following: 



task startHV; 

input rootlnstStr; 

input modeStr; 

input mapStr; 

input inFile; 

input outFile; 

reg [799:0] rootlnstStr; 

reg [799:0] modeStr; 

reg [799:0] luapStr; 

reg [799:0] inFile; 

reg [799:0] outFile; 



The readFIagsHV task is used to read all control flags in the top module. 
Task prototype is the following: 



task readFIagsHV; 

output resetFlag; 

output replayTraceFlag ; 

output clearWeiglitsFlag; 

output stopFlag; 

output quitFlag; 

output biasWeiglitsFlag ; 



The following tasks clear the indicated flags and take no arguments. 



task clearClearWeightsFlagHV; 

task clearResetFlagHV; 

task clearReplayTraceFlagHV; 

task clearStopFlagHV; 

task clearQuitFlagHV; 

task clearBiasWeightsFlagHV; 



The following two tasks make direct calls to the VCS routines $stop and 
$finish, respectively. 



task stopVcsHV; 
task f inisliVcsHV; 



The getCoverMetricHV task calls the $getCoverMetricHV PLI routine. 
Task prototype is 

task getCoverMetricHV; 
input covHandle; 
output coverValue; 
integer covHandle; 
integer coverValue; 



The printCoverlnfoHV task calls the $printCoverInfoHV PLI routine. If 
useRchRag is non-0, then "COMPACT_REACH" is used, else 
"COMPACT'. A value -1 is used for the input coverage handle. Task 
prototype is: 



task printCoverInf oHV; 
input f ileNameStr ; 
input useRchFlag;' 
reg [799:0] f ileNameStr; 

• The readCoverlnfoHV task calls the $readCoverInfoHV PLI routine. Task 
prototype is: 

task readCoverlnfoHV; 
input f ileNameStr ; 
input useRchFlag; 
reg [799:0] f ileNameStr ; 

• The reportDutStateHV task calls the SreportDutStateHV PLI routine. Task 
prototype is: 

task reportDutStateHV; 
input fileStr; 
input modeStr; 
reg [799:0] fileStr; 
reg [799:0] modeStr; 

7-3. Vera Interfacing - CoverBooster 

The CoverBooster program is written in VERA and is designed to interface the VCS 
Slave process with the rest of the CTG system, and to interact with the design-specific 
VERA code which biases and constrains the random simulation process. This section 
outlines the design-independent control flow of CoverBooster. User-specified biasing 
and constraints, compilation methodology, etc are beyond the scope of this document 

Two aspects of CoverBooster are described here: the top-level control flow, and 
stimulus/sampling top-level clocking strategy. 

7.3.1 . CoverBooster Clocking Strategy 

Clocking strategy in the CoverBooster context deals with when inputs are applied and 
coverage measured with respect to the SystemClock used with VERA. This is a separate 
issue from "clocking strategy'* for the Design Under Test itself. The DUT clocking 
strategy might deal with clock dividers, positive/negative registers, edge detectors, etc. 

It is expected that part of environmental specification is to synthesize the DUT clock 
generator in terms of a single SystemClock that CoverBooster knows about. 

Given a SystemClock with period T, Figure 4 illustrates when inputs are applied to the 
DUT and when coverage is sampled. 
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Figure 4. CoverBooster Clocking Strategy 

As shown in Figure 4, all inputs are applied Va clock period before the positive clock 
edge. Coverage is measured 14 cycle ^er the positive clock edge. Formal search 
engines are used Va cycle before the positive clock edge. 

Note that sample points for individual coverage objects may be relative to different 
clocks in DUT (e.g. see the discussion for the $defmeFsmCoverHV() PLI routine). 
Coverage is measured in CoverBooster to determine when all goals are reached, and to 
determine if a replayed trace was successful or not. 

7.3.2, CoverBooster Control Flow 

This section describes key control flow functions in the CoverBooster program. 

7.3.2.1 . Main CoverBooster Program 

Top level control flow is illustrated by the following pseudocode. 

Program Begin 

initialization and read plus args 
wait for first posedge clock 
wait for next negedge clock 
wait for V* more of the clock cycle 
if (testcase replay mode) 

testcaseReplay { ) ; 

$finish( ) 

Endif 
ForEver ( ) 

ReadControlFlags ( ) 
If (resetFlag) 

Call interface reset () task 
ClearResetFlag ( ) 
Elseif (biasWeightsFlag) 

Remember biasing dynamic request 
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ClearBiasWeightsFlag { ) 
Elseif (clearWeightsFlag) 

Call resetWeights ( ) in dynamic interface 

ClearClearWeightsFlag ( ) 
Elseif (replayTraceFlag) 

replaySequence { ) 

Report HIT/MISS to Master 

Setup for dynamic combinational biasing 

ClearReplayTraceFlag ( ) 
Elseif (stopFlag) 

$stop{) 

ClearStopFlag ( ) 
Elseif (quitFlag) 

ClearQuitFlag ( ) 
Break 

Else 

If (dynamic biasing) 

DynamicBiasedDrive ( ) 

Else 

UserBiasedDrive ( ) 

Endif 

Update coverage metric 
Increment clock counter 
Wait for negedge clock 
Wait for clock period 

Endif 

If (no goals left) 
Break 

Endif 
EndForEver 

If (generating test requested) 

Finish writing replay-able test 
Endif - ' 
$stop() 
Program End 

7.3JL2, replaySequence VERA Function 

This function is called to replay a trace (sequence of inputs to apply over one or more 
clock cycles). This trace was generated by one of the formal search engines, and should 
result (usually) in a new goal being hit. 

The file which contains the trace information contains all clocking and input assignment 
information. The replaySequence function simply reads the file and applies logic 1/0 to 
inputs and waits for clocks as instructed. File format is one token per line, and is the 
following: 

• // - Comment lines begin with two forward slashes 

• ! begin! - This is the first token of the replay trace 

• <portName> - This token is a primary input port to the Design Under Test, 
It is followed in the file by 

• <logicValue> - This token is a *0' or *r and is the logic value to drive on 
the port indicated by the previous token. 



46 



• Iclock! - A clock token specifies that a single clock cycle is applied to the 
design. I.E. one clock period of sinnulation time advances. 

• lend! - This token specifies the end of the replay trace. 

If requested, dynamic biasing weights are accumulated as the input ports are driven; this 
information is used later for combinational dynamic biasing. 

The following pseudocode illustrates control flow for this function: 

Function Begin 

OldCover = getCoverageNumber ( ) 
Open trace file 
Text = getNextLineFromFile( ) ; 
If (Text != "Ibegini") 
Error 

Endif 
ForEver ( ) 

Text = getNextLineFromFile ( ) ; 
If (Text == ^Mendi") 

If (biasingWeights) 

accuitiulateWeights ( ) ; 

Endif 

Wait for negedge clock 
Wait for Va clock period 
Break 

Endif 

If (Text == ^Iclock!") 

If (biasingWeights) 

accumulateWeights ( ) ; 

Endif 

Wait for negedge clock 
Wait for clock period 
Continue 

Endif 

LogicValue = getNextLineFromFile ( ) ; 
DriveDataOnPort (Text , LogicValue) 
EndForEver 

NewCover = getCoverageNumber { ) 
If (OldCover > NewCover) 
Report HIT 

Else 

Report MISS 

Endif 
Function End 

7.3^,3. testcaseReplay VERA Function 

This function is called when a complete testcase is to be replayed in stand-alone mode. 
The test file format is an extension of the trace file format. The test file format, in 
addition to the tokens described earlier for trace file, is the following: 

• !test_begin! - This token indicates the begin of a testcase. 

• !run! - a VCS run should be started. The next line in the file is: 
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• <cycIeCouiit> - specifies the number of clock cycles that should be applied 
to the design. 

• ! reset! - a reset sequence is to be applied 

• Ibias_weights! - weights should be accumulated when the next trace is 
replayed. 

• !replay! - a trace is to be replayed. This token is followed by the token 
sequence described earlier for trace replay file format, 

• Iclear! - dynamic bias weights should be cleared 

• !test_end! - This token signifies the end of the testcase 

Pseudocode for the testcaseReplay function is the following: 

Function Begin 

Apply the first reset sequence 
ForEver ( ) 

opcode = getNextLineFroiuFile ( ) ; 
If (opcode =^ test_beginr') 

ReadCoverInf o ( ) // goal definitions 
Elself (opcode == reset!") 
Call reset 0 function 
Elself (opcode == "irun!") 

ClkCnt = getNextLineFromFile 0 ; 
For (i=0; i<clkCnt ; i++) 

If (dynamic comb biasing) 

Dynamic_biased_drive ( ) 

Else 

Random_drive { ) 

Endif 

Wait for negedge clock 
Wait for clock period 

EndFor 

Elself (opcode == 'Mreplayl") 

Rep lay Sequence ( ) 
Elself (opcode == clear!") 

Reset_weights ( ) 
Elself (opcode == 'Mbias_weights ! ) 

Next replay biases weights 
Elself (opcode test_end! " ) 

break 

Else 

Error 

Endlf 
EndFor Ever 
Function End 

7 A. Verilog Program Control - Usage Scenarios 

There are at least three usage scenarios which the verilog-resident CTTG code must 
support, Verilog "plus args" and PLI routines are used to communicate which mode 
analysis is intended. 
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Note: plus args are user-defined verilog invocation switches which are accessible from 
either PLI routines or from VERA code. Plus args which are defined for use by CTG are 
the following: 

• +ctg_mode=<mode_str> - This plus arg is used to specify which mode VCS 
is being used for Currently recognized values are "SLAVE_CREATE", 
"FREE_RBPLAY", and "FREE_CREATE". These are described later in 
this section. 

• +root_dut=<dut__moduIe> - This plus arg specifies which module in verilog 
is the root for formal search methods. 

• +ctg_testfile=<testfile> - In replay mode, this plus arg specifies a testcase 
file which contains control flow for replay of a previously-created testcase. 
In test generation mode, this file is written with the generated test. 

• +ctg_ingoals=<input_goalfile> - This plus arg specifies an input file which 
defines coverage goals for the analysis session. This file optionally also 
contains goals which were covered in previous tests, and are therefore not 
considered in the current session, 

• +ctg_outgoals=<output_goalfile> - This plus arg specifies a file to which 
reached goal information will be written upon process termination. This 
file format is suitable for use as <input_^oalfile> in subsequent sessions. 

The remainder of this section discusses key usage scenarios. 

7.4. 1 . Testcase Creation 

This is the classic CTG mode where formal search and explicit state simulation are 
interleaved to maximize coverage of user-defined goals. Assuming the previously- 
discussed hv_start_vcs„session TCL procedure is used, invocation of the compiled VCS 
simulator looks like the following: 

vcs-exe -s -1 vcs.lag +ctg_testf ile=TestOut \ 
+ctg_inode=SLAVE„CREATE 

This invocation may be slightly different depending on TCL knob settings, and argument 
used to the hv_start__vcs_session procedure. 

The result of this comanand will be to write a testcase control file 'TestOut.ctg", as well 
as reached goals file *TestOut.vgol" when VCS terminates. 

7.4.2. Testcase Replay 

Given a testcase created in a previous CTG session, that test may be replayed in stand- 
alone mode using the following simulator invocation. 

vcs.exe -s -1 vcs.log +ctg_testf il€=<testf ile> \ 
+ctg_mode=FREE_REPLAY +root_dut=<dut_module> 

Where <testfile> was the testcase filename used in testcase creation. <dut_module> is 
the verilog root module name for formal search engines during the creation session. 
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7.4.3. Leveraging User-Written Tests 

A common usage for CTG is expected to be that of augmenting hand-written test 
coverage by use of CTG mechanisms. In this scenario, the hand-written test will cover 
some goals, and CTG will be used to classify those goals not reached by the hand-written 
tests. This section describes how this can happen 

To collect goals which are reached by the hand- written tests, the following actions are 
carried out: 

1 . The user, presumably with some UI help from CTG, defines which goals 
are of interest; these goals are written to a file in a format readable by the 
$startHV and $readCoverInfoHV PLI routine. 

2. The customer links the CTG PLI library to their VCS simulation. 

3. Upon invocation, the user must call the $startHV PLI routine to initiate a 
CTG collection session. This may either be done using the "-f ' verilog 
switch, or by using VCS interactive mode. The <root Jnst> parameter is 
required to be that which will later be formally searched. <mode> is 
"FREE_CREATE". <regMapFile> is <inGoalFile> is the goalfile 
created in step 1). <outGoalfile> is specified; <outGoalFile>.ctg and 
<outGoalFile>.vgol will be written as previously described, 

4. If the user has previously reached goals from an earlier sesison, they may be 
removed from current consideration by calling the $readCoverInfoHV PLI 
routine. 

When this session ends, <outGoalFile>.vgo} will contain the goals which were reached in 
this session, and is suitable as input to a later CTG session. 
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About This Book 

The Vera 4.0 User's Manual is designed to introduce you to Vera-HVL and explain how to de- 
velop Vera tesfeenches for use with Verilog and VHDL designs. The book discusses the basic 
components of the Vera language and progresses to advanced testbendi design topics. The 
book is designed to serve as a supplemental teaching guide as well as a reference guide for the 
advanced user. 



Audience 

This book is intended to be used by engineers with experience with either Verildg or VHDL. 
Because Vera is used to create testbenches that Unk with Verilog and VHDL hardware designs;, 
you should have a fundamental tmderstanding of the description language you are using. This 
book also assumes a limited verification background. Finally, this book assumes use of a high- 
level programming language such as C, C-H^, or Java. 



How to Use This Book 

The first chapter of this book is designed to give an overall view of Vera-HVL and explain 
why it is different than other industry standards. Chapters 2-7 describe some of the basic Vera 
components. Advanced topics are covered in chapters 8-19, 

These are the diapters and a brief description of each: 

• Chapter 1.- Introduction to Vera 

This chapter introduces Vera and briefly describes some of the major features that make it 
one of the premier verification tools in industry. This chapter discusses the flow of data 
using Vera and briefly explains how this flow relates to tesfeench design and usage. 
Finally, this chapter includes brief examples that illustrate basic Vera usage models. 
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• Chapter 2. - Installation and Setup 

This chapter details how to install Vera and setup a user environment. The chapter 
includes licensing information. It also includes instructions on how to recompile HDL 
simulators to link to the Vera simulator. Support information is also located in this chapter. 

• Chapter 3. - Vcra-HVL: The Language 

This chapter introduces the basic lexical conventions of Vera-HVL, It discusses the various 
data types and variable types. This chapter also details some of the more complex data 
types, including arrays and enumerated types. 

• Chapter 4. - Basic Vera Programming 

This chapter discusses the basic components of a Vera program. It includes discussions of 
signal declarations and signal operations, including driving and sampling signals. This 
chapter also includes a detailed discussion of creating subroutines within Vera, 

• Chapter 5. - Sequential Control 

This chapter covers the sequential flow constructs of Vera, including if statements, case 
statements, and for and while loops. It also includes information on sequential flow 
control. 

• Chapter 6- - Concurrent Control 

This chapter discusses the concurrent flow control capabiHties of Vera. It includes a 
detailed discussion of concurrent processes. It also covers triggers, semaphores, regions, 
and mciilboxes, which are key components to controlling concurrent processes. 

• Chapter 7, -Predefined Vera Tasks 

This chapter documents the majority of Vera's predefined tasks and functions. Included in 
this chapter are the tasks and functions associated with file input and output, 
randomizatiorv and error handling. 

• Chapter 8. -Object-Oriented Programing 

This chapter is a brief tutorial on object oriented programming. It describes the basic 
components of object oriented programming and details some of tt\e more advanced 
features such as inheritance and polymorphism. 

• Chapter 9. - Automated Stimulus Generation 

This chapter is a detailed discussion of Vera's stimulus generation features. This chapter 
covers ti\e randonuzation of test packets, constraint-driven stimulus generation, and data 
packing and impacking. 
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• Chapter 10, * Vera Stream Generator 

This chapter discusses the Vera Stream Generator. It includes an introduction to sequence 
generation and includes complete coverage of the system tasks and functions incorporated 
into the stream generator that allow data passing between productions. 

• Oupter 11- - Functional Coverage 

This chapter begins with a brief overview of functional coverage and explains the inherent 
advantages over code coverage. It discusses the use of monitor bins to track simulation 
activities. This chapter also detculs how to set up complex coverage objects that can be 
used for cross-correlation between events. 

• Chapter 12. - Multiple Module Support 

This chapter documents Vera's multiple module support. It detcdls how to create 
testbenches using multiple main programs and incorporate them into a single testbench. It 
covers generation of testbenches using this methodology as well as specific enhancemePtts 
designed to ease testbench creation. 

• Chapter 13- -Vera-CORE 

This chapter introduces Vera-CORE, a feature designed to assist IP vendors and their 
clients. This chapter includes usage models for both the IP vendors and the core users. 

• Chapter 14. -Vera-to-HDL Task Calls 

This chapter provides information on how to make Vera task calls from HDLs and vice 
versa. The specific constructs are discussed along with some of the inherent limitations. 

• Chapter 15. - Calling C/C++ Functions 

This chapter discusses how to incorporate user-defined functions written in C or C++ with 
your Vera testbench. It includes information on how to liiJc in dynamic libraries as well as 
how to call those functioiis from Vera. 

• Chapter 16, -VERA-SV API 

This chapter covers Vera-SV, which allows you to run distributed simulations with some 
Vera modules and some C modules. It includes information on system tasks and functions 
designed to enhance the distributed simulation capabilities of Vera, 

• Chapter 17. - Testbench Setup and Usage Notes 

This chapter discusses how to cormect testbenches to the design under test. It includes 
instructiotis on how to connect HDL signals to the Vera testbench. It also details how to set 
up multiple clocking domains in both Verilog and VHDL. 
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• Chapter 18, - Compilation 

This chapter covers ell of the compiler options used when compiling Vera source code. It 
also includes details on how to use the Vera simulator stand-alone. This chapter discusses 
modular compilation as well, 

• Chapter 19, -Vera Source-Level Debugger 

This chapter describes the Vera source-level debugger. It describes how both the 
text-based and graphical versions of the debugger are used. It explains each of the major 
debugging features incorporated into the debugger. 
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Conventions 

This book uses several style and syntax conventions: 

• Vera keywords are printed in bold. 

• Variables are printed in italics, 

• Signal names, bind names, and user-defined functions are printed as: signal name, bind 
name, user function. 

• Vera statements and variable definitions are printed as: 

connnaiMa_>:eywQrd {variable, argfument) ; 
variable - The definition of variable is described here. 
argument - The definition of argument is described here, 

• Optional arguments are encapsulated by bold brackets ([ J): 

commaiid.keyword {variable I, argument}); 
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1 . Introduction to Vera 

This chapter discusses the current industry standards for high-level design verification, and it 
briefly details the history of Vera. It includes these sections: 

• High Level Verification 

• Why Vera? 

• What Can Vera Do? 

• Overview 

• A Small Example 

• Multiple-Qock / Multiple-Module Systems 

• Simple Example of a 2-Clock System 

1 .1 High Level Verification 

Technology is advancing today perhaps faster than ever. New iimovations in both hardwan; 
and software are extending the capabilities of our computers and building a foundation for z\n 
even more accelerated world of changes and technological advancements. The speed at whicii 
these changes are taking place demands that industry engineers be able to design, build, and 
debug new products with increasing accuracy while still producing them fast enough to meet 
indtistry standards. 

The stress on design integrity is no more evident than in the design and manufacture of inte* 
grated circuits. And while engineers have managed to keep designs ahead of the technology 
curve thus far, the complexity of current designs and the time to verify their functions is he- 
coming a serious concern for chip designers. 

To help in the design process, a nttmber of programming languages have been developed to 
simulate and test hardware desigru To that end, Verilog and VHDL have grown increasingly 
popular in testing design specifications. The power they bring to the engineer to ensure desijjn 
integrity has paved the way for still more sophisticated designs. 

However, in this design world, the reality is that upwards around 75% of the time spent to get 
a chip from inception to market is spent verifying chip design. Even with the power fliat Vier- 
ilog and VHDL bring, designs are becoming increasir^ly difficult arid time constuning to v al- 
idate suffidentiy. To continue to create increasingly complex systems on a chip at the pace 
demanded by the public, engineers need more powerful tools. Hence, Vera was bom. 
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1.2 Why Vera? 

The key to understanding the difference between the current HDLs and Vera-HVL lies in the 
inception of each. The HDLs are designed to be Hardware Description Languages. As such, 
they are adequate for developing hardware models. Vera-HVL is designed to act as a Hard- 
ware Verification Language. Its role exists in an entirely different scope: the verification of com- 
plex ICs and systems. 

The current HDLs are adept at creating hardware models^ which are made up primarily of 
static concurrent processes that simulate individual parts. However, the HDLs provide a level 
of abstraction that is far too narrow to develop useful test envirorunents. The lack of concur- 
rent flow control devices greatly limits the use of multiple threads to simulate a real test envi- 
rorunent Engineers have resorted to programming language interfaces that provide links to C, 
C-h+, and Perl, but even these fall short because these other languages have no concept of 
hardware, timing, or concurrency. 

Vera-HVL provides the necessary abstraction level to develop reliable test environments. 
Through the use of complex synchronization and timing mechanisms, concurrent processes 
can be nm that simulate a dynamic test environment. The implementation of the object orient- 
ed programming methodology further erJiances the ability of the language to work with com- 
plicated designs and sophisticated test benches. 

Add to this Vera's self-checking capabilities, automated stimulus generation, dynamic cover- 
age analysis, and modular approach to programming, and the power of Vera is quite apparent. 

1.3 What Can Vera Do? 

Vera is designed to be a hardware verification language. To accurately simulate complex test 
benches that interact with complicated designs. Vera has a host of features available to its us- 
ers. 

Automated Stimulus Generation 

As chips have grown increasingly complex, the ability to write and perform tests on all the 
functioiis of a system has become nearly impossible. Testing for specific behavior, while possi- 
ble, is far too time-consuming to be a viable verification method. Instead, engineers need a 
method of testing the device under varying conditions and stimuli. To meet these needs. Vera 
provides the engineer with automated stimulus generation. 

The automated stimulus generation process allows engineers to use random stimuli to drive ^ 
the device under test By randomizing the stimuli, engineers can simulate the device xmder 
more conditions and in less time than witti manually-written code. 
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Vera further enhances the automated stimulus generation feature with constraints that give 
the engineer control over the random testing of the chip. The constraint mechanism grants the 
engineer two key advantages: (1) the engineer can weight the tests so that certain sets of stira- 
uli occur more often to simulate a more real enviroxunent, and (2) the engineer can use the 
constraints such that the current model state affects future tests. 

Coverage Analysis 

Because of the complexity of chips and broad scope of functions that need to be tested for any 
given chip or system, the completeness of verification is a key issue. While code coverage 
yields ir\formation about specific lines of code, it does not give any detailed information con- 
cerning functionality. Thus, code coverage is no longer sufficient for complex model verificat- 
tion. 

Vera supports a powerful coverage analysis suite that assures the engineer of the desired cov- 
erage. Specific activities are monitored to ensure that all legal states and transitions have been 
tested. These activities can also be time-stamped to check that specific events happen simuli^- 
neously. 

Vera provides two methods of coverage analysis: open-loop and closed-loop analysis. Open- 
loop analysis performs the tests and then creates a report summarizing the results. Closed- 
loop analysis offers significantly greater power. Using closed-loop analysis, the test suite idein- 
tifies areas of sparse coverage and uses that information to drive subsequent tests. This ap- 
proach guarantees completeness of verification while reducing effort and time spent 

Virtual Ports 

Vera provides a simple way to re-group or re-name interface signals by creating virtual poris. 
Virtual ports allow the engineer to group interface signals so that they can be used more easi- 
ly. These are particularly useful when calling subroutines that you want to act on various in- 
terface signals. By grouping the signals, you can pass them to the subroutine as an argument,, 
allowing you to create signal-independent subroutines. The logical grouping reduces the 
amount of code required to run tests, and makes it easier to comprehend. 

Distributed Simulation . 

Distributed simulation is often used with, but not limited to, hardware/ softW£U?e cb-verifiai- 
tion. It involves verifying l2u:ge desigrts by partitioning verification tasks to run concurrentlly 
across multiple processors. Vera supports distributed simulation by enabling multiple Vera 
programs and C/C-f + applications to execute remote calls to each other across a computer net- 
work. This is particularly useful when verifying complicated system? that tax computer re- 
sources. Distributing the simulation across multiple servers makes the simulation faster and 
more efficient 
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Object Oriented Programming 

Object-oriented programming is at the very core of Vera, The implementation is clear, straight- 
forward and elegant, assimilating and extending the best of the features found in C++ cmd Ja- 
va, By using the object-oriented methodology, programs are easier to design, easier to develop, 
easier to debug, easier to maintain, easier to share, and easier to re-use. 

Object-oriented programming leads naturally to grouping related code and data together, 
keeping these sections smadl, easy to tmderstand, easy to debug and easy to maintain. The re- 
sult is a discipline and program structure that is useful for small programs, but has a dramatic, 
powerful impact on yoxir productivity as soon as your program becomes large or in any way 
complex, 

Verification-Specific Advantages 

Several other key features have been implemented in Vera to enhance its verification capabili- 
ties: 

• Vera supports project-based configuration. Project-based configuration allows the engineer to 
create test benches that are independent of the actual connections to the simulation environ- 
ment, and connect those tesfeenches to any point in the simulation hierarchy without the need 
for a test-top configuration. So, the engineer can run separate test benches with separate pro- 
gram modules concurrently, 

• Vera provides a set of complex synchronization mechaiusms that allow you to use concurrent 
processes in a much more dynamic way. The use of events, regions, semaphores, and mailboxes 
lets you s)aichroni2e multiple signals and threads and simulate complex systems with greater 
ease, 

• Because Vera is designed to verify existing hardware description models, it can interact with 
both Verilog and VHDL designs. This means that engineers can create tesfeenches in Vera that 
will interact with existing Verilog and VHDL code. 

• The modular approach used by Vera makes the use of multiple test benches easy and efficient 
Changes to the hardware design do not require recompilation of Vera teslbenches. Further, 
changes to a tes&ench reqxiire that only the changed testbench be recompiled, 

1 -4 Overview 

This section explains the basics of Vera and how it is used in a real-world context 



Synop^l^fnc. 



Vera 4.0 User^s Manual 



Chapter 1 . introduction lo Vera 21 



1.4.1 How Vera Is Used 

Vera is typically used to develop regressible, self-checking tests for hardware designs. Vera 
test benches are created and linked to existing HDL hardware models using Vera's interface 
construct. Then the Vera driver provides all or most of the stimuli to the device under test 
(DUT). These stimuli simulate input that would be generated by other units in the real system. 
Thus, Vera's role is fundamentally to simulate the external systems that would drive the de- 
vice in a real environment. 

Figure 1-1 diagrams Vera's basic usage model. 



Test bench 
Vera-HVL 



Vera Simulator 




• Behavioral 
models 

• Hardware 
models 

• Other 



Figure 1-1 Typical Vera-CS usage model 

Behavioral models can also be added where appropriate. Memory models and other higWy-al- 
gorithmic modules are good candidates for behavioral implementations rather than mimick- 
ing the features with Vera code. Such models can be written in the HDL or Vera (depending on 
the required functionality). 



1.4.2 Vera Components 

The Vera verification suite includes Vera-HVL, the verification language and language compil- 
ei; the Vera virtual madune, which connects to Verilog and VHDL, and Vera-CS^ the cyde- 
based simulator* The simulator can be lised as a stand-alone simulator; but is most often used 
in conjiinction with Verilog and VHDL designs. 

The Vera virtual machine runs with the Verilog and VHDL simulators, using user-defined in- 
terfaces to convey sigital values between the Vera and HDL domains. Each interface is define<i 
by two main elements: the signals used to drive and sample HDL nodes and a dock that spec- 
ifies all signal timing. The dock determines when signals are driven. and sampled. 
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Simulations are governed by clock edges. All events occur at rising and falling clock edges 
(+/- any skew). As the HDL simulators detect these dock edges, they pass control to Vera. 
Then Vera runs its code non-preemptively imtii it reaches an HDL interface primitive such as 
drive or expect. To execute the primitives. Vera passes control back to the HDL, Because the 
Vera code is run non-preemptively, no simulation time passes while the Vera code executes. 

Vera Simulation 



HDL Simufation 

Figure 1-2 HDL and Vera Execution 

In addition to being able to run with the HDLs, Vera-CS can run with fxmctional circuit models 
written in C or other languages. 

1 .4.3 Vera/HDL Flow of Data 

It is helpful to identify three major regions in the Vera/HDL envirorunent: the Vera domain, 
the HDL domain, and the Vera/HDL interface. Each region has several key components. 

The Vera Domain 

In the Vera domain, there is Vera-HVL, the Vera virtual machine, and a Vera compiler. The 
Vera compiler compiles code written in Vera-HVL and translates it into an intermediate form 
used by the simulator. This intermediate form (.vro object files) can be generated from both 
the main Vera program and any subprograms that may be included. Note that they can be 
compiled separately and linked at simulation time. 

The HDL Domain 

In the HDL domain, there is the hsuxiware description model coded in the HDL and the HDL 
simiilator. The HDL simulator acts in conjimction with the Vera simulator across the Ve- 
ra/HDL interface. 

The Vera/HDL Interface 

The Vera/HDL interface is the most important region of the Vera/HDL environment It in- 
cludes an interface construct, an HDL shell, global variables, and HDL tasks that will be called 
within Vera. 

The interface construct maps signals from the HDL domain to the Vera domain. It specifies 
which signals will be observed and controlled, and determines the flow of data back and forth 
between the two domains. 

The HDL shell is generated by the Vera compiler. It instantiates the interfaces via PLI calls. 
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The global variables and HDL tasks are the shared variables and tasks that are used in both 
domains. 

Figure 1-3 shows a schematic of the flow of data within the Vera/HDL environment. 



Verilog shell Verilog-HDL Circuit 




) Vera object code 

yjQ^ for a sub-program 

sub-program 

Figure 1-3 Vera Environment How 



1,5 A Small Example 

To understand how Vera can be used, we follow the process of verifying a simple Verilog 
module in this chapter. See the tutorial for additioiul examples {$VERA„HOME/ tutorial). 
The following Verilog module is a 2-input round-robin arbitrator. 



module rrarb (req[uest, grant, reset, elk) ; 
input 11:0] request; ( 
output fl:0] grant; 
input reset ; 
input elk; 
wire winner; 
reg last^winner; 
reg [1:0] grant; 
wire [1:0] nextjrant; 

assign next_jgrant CO] 

= -reset & (request [0] & 

(-request [13 | last.winner) ) ; 

— 
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assign next_grant 11] 

= -reset & ( request [1] & 

(-request [0] j -last.winner) ) ; 

assign winner 

= -reset & -next.grant [ 0 ] & 

( las t_winner | next_grant 1 1 ] ) ; 

always ©(posedge elk) begin 
last_winner = winners- 
grant = next_grant; 

end 

endmodule 



The Verilog and Vera source code for this example are available in $VERA_HOME/ sam- 
ples /arbiter . Running the Vera template generator (vera -tern) creates a simxilation en- 
vironment and a test template. The following command line will generate three files, 
rrarb . tes t_top . v , rr arb .if. vrh and rrarb . vr . tmp: 



vera -tem -t rrarb -c elk rrarb, v 



In the command line, -t specifies the name of the module to be tested, -c specifies the dock 
input (optional), and the last argimient, rrarb. v, specifies the Verilog file name. 

The first file rrarb . test_top . v generated by vera -tern is the Verilog simulation top file: 

module rrarb_test_top; 

parameter siinulation_cycle = 100; 

reg SystemClock; 
wire [1:0] request ; 
wire [1:03 grant; 
wire reset; 
wire elk; 

assign elk = SystemClock; 

vera_shell vshelK 

.SystemClock(SystemCloek) , 
. rrarb_reques t ( reques t ) , 
.rrarb_gr ant (grant) , 
.rrarb_reset (reset) , 
.rrarb_clk(clk) 

) ; 

rraxb dut ( 

.request (request) , 
.grant (grant) , 
• reset (reset) , 
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.elk (elk) 

); 

inital begin 

SystemClock s= 0; 
forever begin 

# (sintulation_cycle/2} 

SystemClock = -SystemClock; 

end 
end 
endinodule 

In the top file, the module rrarb is instantiated as dut (device under test) and connected to 
the vera_shell module. The Vera virtual machine uses this vera_shell module to inter- 
face to the Verilog world. A clock signal SystemClock is generated and connected to 
vera.shell's SystemClock. This signal is used to count simulation cycles in the Vera world., 
The input elk is also driven by SystemClock since *-c option was specified. Note that in sys- 
tems with multiple clocks and multiple interfaces, elk and SystemClock can be indepen- 
dent. 

Hie second file, rrarb. if .vrh, contains the interface and signal defiiution. This file is includ- 
ed in the third file, the template file, right before the program declaration, 

interface rrarb { 

output tl:0] request OXJTPUT_EDGE OUTPUT_SKEW; 

input [1:0] grant INPUT_EDGE; 

output reset OUTPOT_EDGE OUTPUT„SKEW; 

input elk CLOCK; 

} 

In this interface file, an interface rrarb is defined with signals on the rrarb module body. 
Output signals of the rrarb Verilog module are defined as inputs, and inputs of the Verilog 
module are defined as outputs in the Vera program interface, except for elk , which is driven 
by verilog top (since the -c option was specified). 

The third file, rrarb . vr . trap, is the Vera program template file: 

♦ include <vera_def ines.vrh> 
♦define 0UTPUT_EDGE PH0U3 
♦define 0OTP0T_SKEW #1 
♦define JKPXJTJSDGE PSAMPLE 
♦include *rrarb.if .vrh* 

// tasks /f -unctions 

program rrarb_test 

{ // start of top block 
// global variables . 

// start of test program 
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// Example of drive: 
// rrarb. request - 0; 

// Example of expect: 
// rrarb. grant ==0; 



} // end of program rrarb_test 



rrarb_test_top 



vera_shell 
vshell 

SystemQock dk 




m 



request 


rrarb 


grant 


duv 


reset 


dk 



Figure 1-4 Top level connection 

Using the template, we can easily write the test code. First, both requests are driven to 0 and 
rrarb. reset is asserted to initialize the internal states. Then grants are checked for each re- 
quest Finally, both requests are asserted simultaneously, and the round-robin control is 
checked. 

#define OUTPUT_EDGE PHOLD 
#define OOTPOT_SKEW #1 
Idefine INPUT„EDGE PSAMPI.E 
# include <ver a_de f ines . vrh> 
f include *rrarb.if .vrh' 

program rraurb_test 

{ // start of top block 

// reset 

rrarb. request = 2'bOO; 
rrarb. reset = 1; 
ei rrarb. reset = 0; 

// siit5>le rec[uesting 
ei rrarb. request = 2*b01; 
ei rrarb. grant — 2'bOl; 
rrarb. request = 2'bOO; 
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@1 rrarb. request = 2'blO; 
@1 rrarb, grant == 2'blO; 
rrarb. request = 2'bOO; 

// round- robin test 

©1 rrarb, request = 2'bllj // requesting both port 

01 rrarb. grant ~ 2'bOl? // should get grant 0, since last was 1 

ei rrarb. grant == 2'blO? // keep asserting both port, get gnt 1 

rrarb. request = 2'bOO; // negate 

> // end of program rrarb_test 



This command line compiles the file: 
vera ~cmp rrarb .vr 

The Vera compiler will compile the rrarb. vr and generate two files: rrarb, vshell, a Ver- 
ilog file that contams the vera„shell modtile, and rrarb- vro^ tiie Vera object file. 

Now run the simulation using Vera with Verilog-XL by typing: 

verilog rrarb. test_top.v rrarb. v rrarb. vshell -»-vera_load=rrarb. vro 

You see a Verilog simulation message such as: 



VERILOG-XL X.X MMM DD, YYYY HH:MM:SS 

* Copyright Cadence Design Systems, Inc. YYYY. 
Compiling source file 'rrarb. t€st_t op, v* 
Compiling source file 'rrarb. v* 
Coir^iling source file ? rrarb, vshell* 
Highest level modules: 
rr arb_tes t„t op 

Vera: finish encountered at time 850 cycle 9 
' total mismatch: 0 

" vca_error: 0 
fail (expected) : 0 
drive: 9 
expect: A 
sample: 0 
sync: 0 

Type ? for help 
Cl> 



1.6 Multiple-Clock/ Multiple-Module Systems 

Vera supports complex docking with any nvimber of derived or independent clocks as well as 
asynchronous interactions flvat fall outside the scope of clocking. Understanding the concep>ts 
in this section is critical in handlir^ system testing and multiple docks. 
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Vera's SystemClock gives Vera a notion of time (cycle number). There are several operations 
that use this as a convenient reference signal. In most cases, it makes sense to tie the System- 
Clock to the actual system clock, but in others it might be offset or derived from another ref- 
erence. 

Most operations are tied to the timing of the actual signals. Independently of SystemClock, 
you can define any niimber of clocking domains (a "Vera interface"), each with its own clock 
reference. 

la simple systems with just one interface, the real system clock, SystemClock, and the inter- 
face clock might be tied together, or just derived from one common signal by assigning differ- 
ent delays. Vera itself imposes no restrictions on the relation between tiie real system clock 
(Vera's reference) and the clocking for each interface. 

Hence, interfaces in Vera are related to the timing of signals as opposed to the boundaries of 
modules or any such implementation-related issue. When you define an interface, you assign 
to it a dock reference. 

Note that you cannot have mialtiple clocks on a single interface because the dock defines a 
clocking domain (interface). Instead, split your signals across multiple interfaces, each one 
with its own dock. 

Sometimes the question arises ''can I haye multiple docks in an interface?" The answer is: "no, 
it doesn't make sense - the dock defines a docking domain (interface) - what you probably 
want is to split your signals across multiple interfaces, each one with it's own clock." 

As a final note, driving of synchronous signals is statically tied to a given clocking domain for 
the duration of a tes&endi. However, sampling can be done in mxdtiple clocking domains by 
connecting a Verilog signal to multiple Vera interfaces, 

1 .7 Simple Example of a 2-Clock System 

In this example we will have a system in which there is a docking module that generates two 
main docks (clkl and dk2). The system contair\s two major portions, each one nmning from 
its own dock- 



// ... 

idef ine TIMING_A PSAMPLE #-1 PHOLD #€ 

♦define TIKING_B PSAMPLE #-2 PHOLD #5 

#define TIMING_C NSAMPLE #0// san^le on falling edge 

tdefine TIMING_D PHOLD #3 



// connect signals to clocking domain 1 
interface siibsysl { 

inout [31:0] data TIMING_A verilog_node •sys.a.subsysl*D[31:03 • ; 

Synop^^nc. 



Vera 4.0 User's Manual 



Chapter 1. Introduction to Vera 29 



output [63:0] addr TIKING_D verilog_node " sys . b . subsysl . A [ 63 : 0 ] * ; 
input elk CLOCK verilog_node •sys.cl}c_geii.clkl"; 
input str TIMING_C verilog„node "sys.str"; 

// 

} 

// connect signals to clocking domain 2 
interface subsys2 { 

incut [16:01 data TIMING_B verilog_node " sys. subsys2 .0(16:0] • ; 
output 132:0] addr TIMING_D verilog_node • sys . subsys2 . A [ 3 2 : 0 ] ■ ; 
input elk CLOCK verilog_node •sys,clk_gen-clk2* ; 
input str TIMING_C verilog_node "sys. str"; 

// 

} 

// connect Vera's SystemClk to "sys.sysclk" 
verilog_node CLOCK "sys.sysclk"; 
//... 



In this example^ Vera will drive subsysl .data 6 time units after the rising edge 
subsysl . elk (same 3S sys , clk_gen . clkl) and sample it 1 time unit before the rising 
edge. 

The SystemClock (the same as sys . sysclk) is used only in relation to calls such as 
get„cycle ( ) , or operations as @ (CLOCK) . AU other sampling, driving, synchronization, etc, 
operations involve specific signals, so they use the timing specified in the corresponding inter- 
face clocks (rather than SystemClock), 
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Note that the Verilog node sys . str is being observed in both timing domains (as 
subsysl . str and subsys2 . s tr, respectively). The only difference is that in each domain we 
are using a different clock reference and a different offset within the clock. You can use multi- 
ple clock references to sample a signal, but you must choose one clock reference to drive. 
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Figure 1-5 Multiple Modules and Multiple Clocks 

There are no restrictions in terms of how each one of these clocks are related. In fact, they can 
even stop and continue independently. Vera only tracks their edges. At that point (plus or mi- 
nus any skew), the signals related to the dock that changed may be driven, sampled, etc, (de- 
pending on what the test code may be doing). 
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2. Installation and Setup 

This chapter details the installation and setup of the Vera verification suite. It includes these sections: 

• Installation 

• Licensing 

• Running Vera with Verilog-XL 

• Running Vera with Chronologic VCS 

• Running Vera with the Verilog ModelTech Simulator 

• Running the Vera Stand- Alone Simulator 

• Testing the Installation 

• Vera Support 

2.1 Installation 

1 . Create a release directory on the machine you want to act as your Vera server, 

2, Download the Vera release to the release directory you created. The ftp address is provided by Synop- 
sys. Email vera-support@synopsys,coni for help. 

3. Set the en viroimient variable VERA_HOME pointing to the Vera release directory: 

setenv VERA_HOME <directory_path> 

4, Add $VERA„HOME/bin to your search path. 

2.2 Licensing 

Vera 3,1 and higher uses the industry-standard FlexLM licensing system, 

2.2.1 Licensing for Current FlexLM Users 

If you use FlexLM, check that your V^a key is for the same scrver(s) that show in your current 
$liM„LlCENSE_FILE, add the Vera feature to your license file, and then add the daemon line for 
$ X^R?V_HOME/ bin/ s s i Imd. 

2.2.2 Licensing for Other Users 

Vera uses the industry-standard FlexLM licensing system, which provides floating licenses for a net- 
worked cnviroimient To license your version of Vera, you need to do 4 things: 
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1 . Obtain your Scrver-ID. 

2. Edit your Hex license file to add the absolute path to the Vera verification tool ($VERA_HOME) and 
the Synopsys license daemon ($VERA„HOME/bin/ssilmd). 

3. Set LM_LICENSE_FILE to pomt to the license file. 

4. Start the FlexLM license server. 

For more information, use any Web browser to view the HTML data in: 
$VERA_HOME/doc/ f lexlm/man • htrcd 

Getting the Server-ID (imhostid) 

Hex network floating licenses are managed from one server (or more, when redundant servers are set 
up). When you purchase Vera licenses you need to specify the server(s) for which the keys should be 
hosted, including both their name and their Hex-ID. To get the Hex-ID, type the following from a Unix 
shell: 

For SPARC servers: host id 
For all other servers: Imhostid 

The Imhostid executable can be found within the Vera release, in: 

$VERA_HOME/bin/lrcihostid 
or on the Synopsys FTP site; 

ftp * systems . coia 
To use the FTP site: 

1 . Use your FTP tool to connect to the Synopsys FTP site. Log in with the usemame anonymous and pass- 
word anonymous. 

2. Change to the directory designated for your server type: 

cd /pub/ssi/<server_type> 

where Kserverjtypo is sunos, Solaris, hpux, aix, SGI, or ALPHA. 

3. Make sure you are in binary mode. Download &e apped executable: 

get Imhostid. gz 

4. Download the grip tool if your site does not already have it: 

get gzip 

5. After exiting FTP, make sure the zipped executable is in the directory you want 
($VERA„HOME/bin/ Imhostid is preferable). Then decompress the zipped file: 

gzip -d Imhostid, gz 
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6. Set the permissions on the executable: 
chmod a+x Imhostid 

FLEXIm License File Contents 

The FLEXIm license file contains 3 important pieces of information: 

1. Server line: 

SERVER <server_name> <sexver^lmhostid> <port> 

Make sure the key you got is for the proper hostid/hostname. There should be only one server line per 
Flex license file. 

For example: 

SERVER mars 12345678 1700 

2. Daemon line(s): 

DAEMON ssilind <ahsolute_j>ath^to^ssilmd_Jbinary> 

You must use the absolute network path WITHOUT environment variables to a copy of the Synopsys 
license daemon found in $VERA_HOME/bin/ss±lm± In a given FlexLM file there can be 1 daemon 
line for each vendor. 

For example: 

DAEMON ssilmd /net/ jupiter/home/cad/ssi/vera/bin/ssilmd 

3. Feature line(s): 

FEATURE <tool> <daemon> <vGrsion> <expirBS> <nvm> <key> 
There will be one feature in your LM license file for each tool. 
For example: 

FEATURE vera ssilmd 3.000 31-dec-96 2 BB6E7071B0C8C9877168 

LM_LICENSE_FILE Environment Variable 

You tell FlcxLM where your keys are by setting an environment variable as follows: 
setenv IJ1_LICENSE_FII^ <path^to^our^llcense^file> 

Each license file may contain Ucenses for many packages and from multiple vendors. It is simplest to 
have all your licenses in one file. However, you can specify multiple files as follows: 

setenv LM_LICENSE„FILE <path_to^filel>z<path^to^file2>z<pat±^to^flle^^ 
Add this command to your .login or .cshrc files to ensure that it is executed upon logging in. 
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Starting the Flex License Manager 

If il is not already running on the host server, start the license manager by typing from the Unix com- 
mand line: 

$VERA_HOME/bin/lmgrd -c <vera^license_file> >& /tir^/f lexlmgrd. log 
If it is already running and you want Rex to know about your update to the license file, enter 
$VERA_HOME/bin/ Imreread 



Note - Use •'Imgrd" version 5.0 or higher. If you are using an older version 
supplied by another tools vendor, you may need to upgrade to the "Imgrd" 
supplied with Vera (which would also provide the backwards compatibility 
for tools that use older FlexLM versions). To find out the version of a given 
Imgrd, enter Imgrd -v at the command line. 



Versions Enabled and Backwards Compatibility 

License keys for higher versions of the software enable lower versions as well. Also, Vera licenses ig- 
nore any decimals in the version number except for the 1st one (e.g., a key for version 4.40 will enable, 
vera-3.1, vera-4.0, and vera-4.49, but not vera 4.5). 

Versions 3.0 or lower did not use HexLM. You can run in your environment a mix of Flex and non-Flex 
based Vera versions. However, beware that the license files, servers, and environment variables are un- 
related and cannot be combined. You can have both the old SSI license manager and Flex running, have 
both the old SSLLICENSE and LM_LICENSE„FILE environment variables set. As long as your 
search path is set to pick the right Vera/HDL versions, you should have no problems. 



2.2.3 Controlling Vera License Queueing 

The environment variable VERAJ^AITJJCENSE allows you to control the checking out and queueing 
order of full and runtime Vera licenses. The syntax from the Unix conmiand line is: 

setenv VERA_WAIT_LICENSE value 

vaUie ' The value can be cither 1, which queues up for runtime if both fiill and runtime licenses are 
unavailable, or 2. which polls for either license every 10 seconds if both full and runtime licenses 
are unavailable. All other values^ (or if VERA_WAITJJCENSE is not set) terminate the simulation 
if neither license is available. 

Note - The environment variable SSI_WAIT_LICENSE must not be set 



2.3 Running Vera with Chronologic VCS 

You must generate a new Chronologic VCS simv executable with each new hardware description. To 
link it to Vera, you need to invoke vcs with the following arguments: 

a) your verilog model(s) 
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b) option "-P SVERA_HOME/lib/vera_pli.tab" to specify the PLI table (or merge this PLI table with 
other ones you may already be using) 

c) the SVEMJlOMEAib/libSysSciTasha library 

For example, to generate a new simv executable for a design modeLvj enter 

vcs model, V -P $VERA„HOME/lib/vera_pli. tab $VERA„HOME/lib/libSysSciTask-a 

If you are using SunOS, you need to run ranlib before linking the libSysSciTaska library: 
ranlib $VERA_HOME/lib/libSysSciTask , a 

If you arc using HPUX, you must invoke the following options in addition to those specified previous- 
ly: 

-K -gen_c -liDFLAGS -a archive„shared" -Idld 

For example, to generate a new simv executable for a design modeLv, enter 

vcs model. V -Mupdate=l -gen„c -P $VERA^HOME/lib/vera_pli.tab \ 
$VERA_HOME/lib/libSysSciTask.a -LDFLAGS "^E -a archive„shared' -Idld 

2.4 Running Vera with Verilog-XL 

To use Vera with Verilog-XL, you must link the libSysSciTask^a library into your Verilog executable. 
You must do this only when first using Verilog-XL with Vera. 



Note - Version 3.1p4 of Vera and later versions dynamically load the vcra.dl 
library. If you've previously linked your Verilog-XL with libSysSciTask.a,, 
you DO NOT need to relink it Just change your VERA_HOME environment 
variable, and Verilog-XL will automatically use the venudl library in the new 
Vera release. 



Environment ' 

You must have the Cadence binaries and the C-compiler in your search path. To make sure they are set 
correctly, add the following to your xshrc file: 

# tools 

•setenv CDS_INST_DIR <pat:h_t;o_CADENCE_install_directory> / tools . <arch> 
setenv C_C0MPILER^H0ME<path„to_C_con5>iler_install_directory> 
# 

# search pat:h 

set path = ($path $CDS.INST_DIR/bin $C_COMPILER_HOME/bin) 
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veriuser.c 

The file veriuser.c contains information thai Verilog uses to link in user-defmed system tasks. You 
must include these files in your veriuserx file: 

viac_veri„f unext .h 
vinc_veri_f undef . c 

If you have other tasks that have to be linked in, such as PowerFault-mDQ's. you need to combine 
what is included in SVERAJIOMEAib/veriuserx with the veriuserx for the other tasks. 

vconfig 

The vconfig procedure creates a cr„vlog script, which is used to link Vera into the new Verilog execut- 
able. To run vcongif: 

L Begin vconfig: 

vconfig 

If you get a message saying: "vconfig: Command not found", it means that your search path is missing 
Cadence's $CDSJNSTJ>lR/tools/bin directory. 

2. At the following prompt: 

The user terc^jlate file 'veriuser.c' must always be included in tlie link 
statement. What is the path name of this file? 

Enter the path to your own veriuserx, 

3. At the following prompt: 

List the files one at a time, terminating the list with a single ' . ' 

Enter 

. / 1 ibSy s Sc iTask . a 

Then specify any other libraries you may need to link in (1 per line). After all the libraries have been 
specified enter a single period (.) on a new line. 

The vconfig program will create a script named cr^vlog (or whichever name you choose when prompt- 
ed). 

Before Running cr_vlog 

If you are using HPUX 9,0 or HPUX 10.2, your cr_ylog must use the "-Wl,-E" compile option. Change 
the "cc" command from: 

cc -o verilog 

to: 

cc -Wl,-E -o verilog 

r 
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If you are using either Verilog-XL version 2.X OR you are using HPUX 9,0, you must also link with 
the "-Idld" library. Check that one of the last lines of your cr_vlog file matches the following: 

+03 -Im -IBSD -Icl -N -Idld 
If you are using SunOS, you should run ranlib before running cr^vlog: 

ranlib suiios4 .l/libSysSciTask,a 
If this step is omitted, you will get link complaints when you invoke cr^vtog. 
If you are using Solaris, your cr^vlog script must link with these libraries: 

-Isocket -Insl -lintl 
Check that these libraries are included in your cr^vlog script 

Running cr_vlog 

When you run the cr_vlog script you will compile a new Verilog executable with the libSysSciTask.a li- 
brary. To run it, enter. 

cr_vlog 

Install the new Verilog executable you created the directory you want to run it from. Note that if you 
chose to name the new executable "verilog", you should have $VERA/bin ahead of SCA- 
DENCE/tools/bin in your search path, so that the right version of Verilog is picked up. 

2.5 Running Vera with the Verilog ModelTech Simulator 

You must recompile your MTI simulator and link it with Vera before running any simulations. To re-" 
compile your ModelTech simulator: 

1. Compile veriusenc for the MTI simulaion 

For Solaris, type: ^ , 

CO -K pic -DMTI -DaccVersionLatest -c -X<modeltec}K-±nclude_dir> V^: 
-I$VERAJHOME/lib veriuser.c 

OR 

gcc -fpic -DMTI -DaccVersionLatest -c 'l<modeltech„include_dir> \ 
-I$VERA_HOME/lib veriuser.c 

Then type: 

Id -G -o veriuser.so verixiser.o libSysSciTaskpic.a 
For SunOS, you must run ranlib libSysSciTask.a prior to compiling. Then type: 

CO -DMTI -DaccVersionl/atest -c -l<modeltech_include_dir> \ 
-I$VERA_HOME/lib veriuser.c .^ClT 
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Id -o veriuser.so veriuser.o libSysSciTaskpica 
For HPUX, type: 

cc -DMTI - Dace VersionLa test -c +z -I<modeltech_include_dir> \ 
-I$VERA_HOME/lib veriuser.c 

OR 

gcc -fpic -DMTI -DaccVersionLatest -c -I<iaodeltech_incl'ude_dir> \ 
-I$VERA_HOME/lib veriuser.c 

Then type: 

Id -b -o veriuser.sl veriuser,o libSysSciTaskpica -Ic 

2. Set up ModelTech to load veriuscnso (veriusensl for HP). 

Edit vsystemini or modelsimini to include: 
[vsim] 

Veriuser = $VERA„HOME/lib/verisure. so 

OR 

setenv PLIOBJS $VERA_HOME/lib/veriuser . so 

OR 

-pli $VERA_HOME/ lib /veriuser. so 

2.6 Running the Vera Stand-Alone Simulator 

Vera can be used by itself as a concurrent programing language. As such, it is a cycle-based simulator, 
which can run Vera models stand-alone or linked with additional C models. The pre-compiled copy of 
this simulator is in $VERA/home/binA^eraucs. If you want to link in your own C code to this simulator, 
instead of using the pre-compiled copy above, you must compile verajusenc and Unk it widi 
$VERA_HOME/libAibVERA.a. Additionally, if you arc using a Solaris platform you must link in 
-Isocket -Insl -lintl along with any other appropriate libraries. See Section 18,8, **Rimning Vera Stand- 
alone" for usage of the resulting simulator. 



Note — If you do not use Verilog-XL and do not have the veriusenh file 
available, you must define •'NO_VERILOG_SIM'' from the command line 
when you compile verajusenc. 
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2.7 



Testing the Installation 



Make sure that the Verilog executable in your path is called verilog and that it is linked with the 
Vera tasks. In $VERAJiOME/samples there are complete examples, each with a doit script. To test 
the installation, check that the scripts compile the tests and run Vera with Verilog. 



Please use the following email addresses for Vera-rclated issues: 

Technical issues: 

Customer Support (setup, bugs, help): vera-support@synopsys.com 

Enhancement Requests: vera-enhance@synopsys.com 

Documentation Issues: vera-doc@synopsys.com 

Other Feedback: vcra-feedback@synopsys.com 

information, Sales, and Licensing: 
Licensing: vera-license@synopsys.com 

Sales Information: vera-5ales@syn0psys.com 



2.8 



Vera Support 
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3. Vera-HVL: The Language 

This chapter describes the basics of Vera-HVL, It introduces the lexical conventioiis and^some 
of the basic components of the language. It has these sections; 

• Lexical Conventions 

• Data Types and Variable Declaration 

• Arrays 

• Strings 

• Enumerated Types 

• Vera Operators 

• Variable Assignment 

3.1 Lexical Conventions 

Vera-HVL source code consists of a stream of lexical elements. The types of lexical dementis 
are: 

• White space 

• Comments 

• Statement Blocks 

• Identifiers and Keywords 

• Strings 

• Nimibers 

3.1.1 White Space 

White space is any sequence of spaces, tabs, newlines, and formfeeds. White space is used in 
Vera as token separators. Whitespace can be used freely and is ignored by Vera, except witliin 
a string. 

3.1.2 Comments 

Vera supports two forms of comments; a one-line comment and a block comment, 
A one-line comment starts with a double slash (//) and finishes out the line. The syntax i>: 
anyi^vera^statement; // One line comment. 

A block statement starts with a /* and ends with a */. Everything between the start and end 
tags is a comment The syntax is: 
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/* Blocks of comments 
can take up 
multiple lines */ 

Note - Block comments cannot be nested. 



3.1.3 Statement Blocks 

Vera supports three methods of creating statement blocks: begin/end, braces, and fork/join. 
The syntax for begin/end statement blocks is: 

begin 

vera_s ta t emen ts 

end 

The syntax for statement blocks using braces is: 
{ 

vera_statenients 

; 

The syntax for fork/join statement blocks is: 

fork 

processl () ; 
process2 () ; 

processNO ; 
join 

Forks and joins are discussed in more detail in Section 6.1, "Fork and Join." 

3.1.4 Identifiers and Keywords 

An identifier is a sequence of letters [a-zA-Z], digits[0-9] and xmderscoresIJ. Identifiers are 
case-sensitive and cannot begin with a digit. 

In addition to the Vera keywords, all signal types should be considered keywords. Table 3-1 
lists the Vera signal types. 

Table 3-1 Vera Signal Types 



ASYNC 


CIjOCK 


NDRIVE 


NHOLD 


NRX 


NRZ 


NRO 


NRl 


NSAMPLE 


PDRIVE 


FHOLD 


PRX . 


PRZ 


PRO 


PRl 


PSAMPLE . 
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Vera also uses a set of predefined q_values with its Value Change Alert implementation 
(Section 4,45, "Value Change Alert (VCA)")- Table 3-2 lists the predefined q.values. 



Table 3-2 VGA q.values 



gnr 






grl 


giO 


nr 


rx 


rz 


rO 


rl 


snr 


srx 


srz 


siO 


srl 





Vera has several predefined system functions and system tasks whose names must not be used 
as program identifiers. Table 3-3 lists the predefined identifiers. 



Table 3-3 Vera Predefined System Functions and Tasks 



alloc 


call_func 


call^task 


cast_asslgn 


dose.conn 


delay 


error 


error_mode 


exit 


fdose 


fflush 


flag 


fopen 


^rintf 


freadb 


freadh 


freadstr 


get_bind 


get„bind_id 


get_conn_err 


get_cyde 


get_plus_arg 


get_systime 


get_time 


mailbox„receive 


mailbox_send 


make.dient 


make_server 


printf 


rand48 


random 


region_enter 


region.exit 


rewind 


semaphore^get 


semaphore, 
put 


sprintf 


sscanf 


stop 


sync 


timeout 


trace 


trigger 


utut.delay 


up^connections 


urand48 


urandom 


vsv_call_func 


vsv_call_task 


vsv.dose^cdnn 


vsv_get_con_ 
err 


vsv_make_ 
client 


vsv_make_server 


vsv_up_ 
connections 


vsv_wait_for_done 


vsv_wait_for_ 
input 


waitjchild 


wait^var 
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Vera has several predefined system macro constants whose names must not be used or rede 
fined without proper system tasks. Table 3A lists the predefined constant identifiers. 



Table 3-4 Vera Predefined Constants 



stderr 


stdin 


stdout 


AT T 


AJ\Y 


DAD-blAlt 


uALJ^ 1 fsAINo 




CHGEDGE 


CLbAK 




f^Vr\CQ TP A KTC 


DEBUG 


UELbrb 


tr/^ A 0"D A VY 
t AKKA I A 




EC_CONFLICT 






li^^-.MoA i MUU i 


EC_NEXPECT 


EC„RETURN 


EC_RHNTMOUT 


EC„SCONFLICT 


EC.SEMTMOUT 


EC.SEXPECT 


EC.SFULLEXPECT 


EC_SNEXPECT 


EC^USERSET 


EQ 


EVENT 


HRST 


GE 


GOAL 


GT 


HAND^SHAKE 


HI 


HIGH 


HNUM 


LE 


LIC_EXIT 


UC.PRERR 


UC.PRWARN 


UC„WAIT 


LO 


LOAD 


LOW 


LT 


MAILBOX 


NAME 


NEGEDGE 


NEXT 


NO_OVERLAP 


NO.WATT 


NUM 


NUM_BIN 


OFF 


ON 


ONE.BLAST 


ONE.SHOT 


ORDER 


POSEDGE 


PROGRAM 


RAWIN 


REGION 


REPORT 


SAVE 


SEMAPHORE 


SET 


SILENT 


STATE 


STR 


STR„ERR_OUT^OF^ 
RANGE 


STR_ERR_REGEXP. 
SYNTAX 


SUM 


TRANS 


VERBOSE 


WATT 







3.1.5 Strings 

A string is a sequence of characters enclosed by double quotes. A string must be contained in 
a single line unless the new line is immediately preceded by a back slsish. In this case, the back 
slash and new line are ignored. 

3.1 «6 Numbers 

In Vera, a number can be formed using either the LIT_INTEGER or NUMBER format. 

The LITJNTEGER format is a simple decimal number specified as a sequence of digits from 0 
to 9. Negative signs are allowed to specify negative integers. Underscores are ignored and 
may be used for clarity. The syntax is: 
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[0123456789]+ 
The NUMBER format takes these forms: 

<size>' <base><nuiBber> 

<stze> - The <size> specifies the number of bits in the number. The size upper limit is 
dependent on the host machine, but it is generally 32 bits. If the <size> is omitted, the 
number of bits for <number> defaults to the host machine word size, A plus or minus sigi:\ 
before the <size> specification signifies ti\e ntmiber's polarity. 

<has€> - The <base> is always preceded by a single quote O- The <base> can be one of the 
following: d(ecimal), h(exadedmal), o(ctal), or b(iimry). The base identifier can be either 
upper or lower case* 

<numher> - The valid elements of <number> for each <base> are: 

'b (binary): (OixXzZ.j 

'd (decimal): [0123456789_j 

'o (octal): [01234567xXz2_l 

'h (hexadecimal) : t0123456789abcdefABCDEFxXzZ_3 

X and X represent unknown values^ and Z and z represent high impedance values in 
binary, octal, or hexadecimal form. Underscores are ignored. 

If the most significant specified digit of a <number> representation is an x or a z, the Vera com- 
piler extends the x or z to fill the higher order bits or digits. For example, STdx means 
S'bxxxxxxxx, or S'bzOO means SIjzzzzzzOO, 

3.2 Data Types and Variable Declaration 

Vera's basic data types dcce integers, bits, strings, events, bind.var, classes, and entmierated 
types. You can also make composite types of the base types with surays, associative arrays, 
and records. 

Variables are seen globally if they are declared at the top (program) leveL If they are declared 
in blocks (begin/end, {). fork/join), they are seen locally. 

3.2.1 Integers 

Integers are signed variables. They can have integral values between 1-2^^ and 2^^-l. An inte- 
ger may become X (imknown) when it is not initialized or when an undefined value is stored. 

The syntax to declare an integer is; 

lzite9er variable^name - ±niti&l__value; 

The initialization is optional in tiie variable declaration. 
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Note - For expressions involving both bit and integer types, the 
integer types are first converted to 32-bit unsigned integers. 



3.2.2 Bits 

Bits can have the value 0 Gogic 0), I (logic 1), z (high impedance), or x (unknown). 
The syntax to declare a bit is: 

bit variahle^name = initial^value; 
The initialization is optional in the variable declaration. 
Vera also supports bit fields. The syntax to declare a bit field is: 

bit [high: low] variable_name = initial^value; 

High specifies the upper limit on the field, and low specifies the lower limit on the field. The 
maximum size of a bit field is 4095 bits. When declaring bit fields, you caimot use variables for 
high and low specifiers. 

Vera also supports registers. Registers in Vera are identical to bit vectors. The syntax to declare 
a register is: 

reg [high: low] variable^name = initial_value; 

3.2.3 Strings 

Strings are character data types that have a wide range of operators associated with them for 
manipulating characters. 

The syntax to declare a string is: 

•tring variahle^name = initial^value; 
The initialization is optional in the variable declaration. 

Strings and string operators are discussed in more detail in Section 3,4, "Strings.'' 

3.2.4 Bind_vars 

Bind_var variables hold binds. Binds are used to group and associate signals with ports. 
Bind_vars are used with task calls to specify which port the task call commimicates with. For 
more information concenung binds, see Section A33, '^ind." 

The syntax to declare a bind_var is: 

biiid_var variahle^name = initial_yaluG; 
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The initialization is optional in the variable declaration. 

Bind_vars are discussed in more detail in Section 4.3.4,1, "bind_var Variables." 

3.2.5 Events 

Events are variable types xised to maimge triggers. They exist in one of three states: OFF, ON, 
and null. Events are passed as argximents to task, function, and method calls to specify flie 
trigger point They are used mainly to synchronize concurrent processes. Synchronization and 
the use of events is discussed in more detail in Section 6,2, "Events." 

The syntax to declare an event is: 

event variahle^name « initxal^value; 

The default initialjaalue is OFF. You can only initialize events to null, which has the effect of 
the trigger always being ON, 

3.2.6 Enumerated Types 

Enumerated types are named integer constants. The syntax to declare an enumerated type is: 

exam category *= list; 
OR t 

eaum category {list) 

The category is the name of the enumerated type. It is used to assign list values to variables. 

List is a list of category values separated by commas. They are assigned sequential integer val- 
ues in the order listed. ^ ' 

Enumerated types are discussed in more detail in Section 35, "Enumerated Types.* 

3.2.7 cast_assignO 

Vera provides the cast_assignO system function to assign values to variables that might not 
ordiruirily be valid because of typing. The syntax for cast.assignO is: 

ca«t_&s«igxx(dest.var, source^exp t, check}); 

destjoar - The djestjoar is the variable to which the assignment is made. It can be any 

non-array scalar type (bits, integers, strings, enumerated types, bind.vars, port variabl<»s, 
events, and object handles). 

, source^exp - The source^exp is the source expression ihat is assigned to the destination 
variable. 
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check - The check modifier can optionally be specified using CHECK. Its use determines how 
the function handles invalid assignments. 

When the cast_assign() system function is called without the CHECK modifier, the function 
assigns the source expression to the destination variable. If the assignment is illegal, a fatal 
runtime error occurs. When the cast.assignO system function is called with the CHECK mod- 
ifier, the function makes the assigrmient and returns a 1 if the casting is successful, or it does 
not make the assignment and returns a 0 if the casting is unsuccessfuL In the latter case, no 
runtime error occurs, and the destination variable is set to NULL, X, or iminitialized, depend- 
ing on the data type. 



Note - The compiler only checks that die destination variable and 
source expression are scalars. Otherwise, no type checking is done at 
compile time. 



These are examples of the cast_assignO system function: 

cast„assign(my_eniim, 12*7) ; 
cast_assign(iny_portvar, iny_bindvar) ; 

The first example assigns the expression to the enumerated type. Without cast.assignO, this 
assigiunent is not allowed because of strong typing of enimierated types. The second example 
assigns the value of the bind_var to the port variable. Again, this assignment is not possible 
without cast_assign() because of strong typing of port variables. 

A discussion of the cast_assign() system function and its use with objects is in Section 8.12, 
"Casting." 



3.3 Arrays 

Vera supports one-dimensional arrays, which axe lists of variables that are all of the same type 
and called with the same name. Arrays in Vera can be static (global) or dyrmmic (local). You 
can also create associative arrays that have ti\e advantage that each entry of the array gets al- 
located only when it is accessed. 

3.3.1 Arrays 

Any variable type can be declared as an array. The syntax to declare arrays is: 

Integer array_,nameisize] ; 
bit ihigh:l ow] array^name [ si ze ] ; 
bind_var array_namelsize'i ; 
event array_name [ si ze 3 ; 
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size - The size specifies the number of elements in the array. The maximum number of 
elements in an array is 2'^'^31-1 elements. For larger arrays, you should use associative 
arrays. 

Accessing an array with an imknown bit ('x') in the index causes a simulation error. Also, 
writes to an array with an imknown in the index are ignored, and reads with an xmknown in 
the index return 'X's, 

Note that a bit field of an array element cannot be referenced directly. To reference a bit field 
of an array element, use a temporary variable. For example: 

tn^ = inemory[42]; 
if (titqp[3:2] 0) 

You caimot initialize an array in the declaration. 

3,3.2 Associative Arrays 

Associative arrays are arrays whose dimensions are not specified. The syntax to declare asso- 
ciative arrays is: 

integer array_namei] j 
bit [highilow] array^nameU : 
bind_v«x array_name 1 3 ; 
event array^name [ 3 ; 

Array elements in associative arrays are allocated dynamicaUy, when you access a particular 
address. The array index tracks ttiose elements that have been assigned values and stores 
those values within the array. When using integer and bit associative arrays, if you try to ac - 
cess an element that has not been assigned a value, an 'X' is rehimed. When using bind„var 
and event associative arrays, if you try to access an element that has not been assigned a val- 
ue, a NULL value is returned. 

Note - Using associative arrays slows down simulation time slightly, 
though the effect is usually ttnnoticeable. 

Vera supports several mechanisms for analyzing associative arrays: 

usoc_ixidex (CHECK, &rray_name, index) ; 
ftssoc.index (DELETE, array_naine, index) ; 

The array jname is the name of associate array you are analyzing. 

The index is the numerical index of the element you are analyang. 

The CHECK function checks if an element exists at the specified index within the array. If it 
does, a 1 is returned. If it does not, a 0 is returned. 
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The DELETE function deletes the element specified at the specified index. If it is successful, a 
1 is returned. If the element does not exist a 0 is returned. 

Vera supports two additional functions used with associative arrays: 

asfloc_index (FIRST, array^name » index^var) ; 
assoc_index (NEXT, array^name, index^var) ; 

When the FIRST keyword is used, the function returns the element associated with the first 
valid index. The index joar is assigned the value of the first valid element in the array. The 
function returns a 1 if it is successful and a 0 if it fails. 

When the NEXT keyword is used, the function returns the element associated with the next 
valid index. The index joar is assigned the value of the next valid element in the array. The 
function returns a 1 if it is successful and a 0 if it fails. 



ZA Strings 



Within Vera, string data types are defined as classes. Vera also defines a set of internal vari- 
ables and class methods used to analyze and manipulate strings, 

3.4.1 Printing Strings 

Vera strings are printed using the C-style printf function. The syntax to print a string is: 

printf { * s tring^forma f , variables) ; 
Vera uses several predefined format specifiers. Table 3-5 lists Vera's format specifiers. 

Table 3-5 Vera's Format Specifiers 

Form at Specifier Fomiat 

%d or %D a decimal number 

%h or'%H or %x or %X a hexadecimal number 

%o or %0 a octal number 

%b or %B a binary number 

%c or %C a single character 

%s or %S a string 



The format specifiers are: %d or %D (decimal), %h or %H or %x or %X (hexadecimal), %o or 
%0 (octal), %b or %B (binary). You can also use %s or %S to read in a string, or %c or %C to 
read in a single character. 
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By placing a number before the format specifier, you can specify how many digits are read La 
a particular number. If you want to minimize field width, use a 0 before the format specifier. 

You can also use escape characters for formatting. Table 3-6 lists the Vera escape characters. 



Table 3-6 Vera Escape Characters 



Escape String 


Character Produced 


\n 


new line 


\t 


tab 


W 


\ 


\" 




\ddd 


a character specified in 1 to 3 octal digits 


%% 


% 



3,4.2 Valid Operators 

Vera provides a set of operators that can be used to manipulate combinations of string vari- 
ables and string constants. Table 3-7 lists the valid operators. 



Table 3-7 


Valid Operators 


Operator 


Meaning 




Check equality of two strings 


!= 


Check inequality of two strings 




Generate a concatenated string with strl, strl, 


{ntmz{str}} 


Generate a string duplicated num times. 



Note - You can compare string variables to nuIL 



3.4.3 String Class Methods 

Vera's string functions behave as class methods. Therefore^ the string being analyzed must be 
specified in the method call* The syntax to madce method calls is: 

string^name.fxmctioni) 
stringjname - The stringjname is the string that is the target of the method call. 
function - The function is the name of the method being called. 
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3.4.3-1 General String Class Methods 

Vera provides a set of general functions (or methods) to handle hidden values within string 
vciriables, 

lenO 

The lenO function returns the length of the string as an integer. The syntax is: 
s tring^name . len ( ) ; 

For example: 

string str; 

str = *This is a string'; 

printf ( ^String length = %Od\n', str.lenO); 
This example prints the string length of string str. 

getcO 

The getcO function returns a character at a specified location. The sjnntax is: 

s tring_naine , getc ( i ) ; 
i - The i parameter must be an integer value. 

The function returns the character specified by i. If the parameter is larger than the given 
string, 0 is returned. 

For example: 

string str = *This is a string*? 

printf(*The fifth character is %c\n', str.getc(5)) ; 
This example prints the fifth character in string str.ls a bit function that 

putcQ 

The putcO task assigns a jgiven character to a specified location. The syntax is: 

s tring^name . put;c ( i , * char* ) ; 
i - The i parameter must be an integer value, 
char - The char parameter must be a bit 

The task stores char in ti\e i position within the string. If f is larger than tiie string, char is ig- 
nored and the internal flag STR_ERR_OUT_OF_RANGE is set. 

For example: 

string str = •X23456789'; 

str.putc(0, ^ jdfer 
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This example sets string sir to "123456789". 
get.statusQ 

The get_statusO function returns the current status flag value as an integer. The syntax is: 
string_na2ne.ffet_stat:us ( ) ; 

The possible values are 1, which corresponds to STR_ERR_OUT_OF.RANGE (set by putc), 
and 2, which corresponds to STR_ERR»REGEXP_SYNTAX (set by match). K there is no flag, 
the function returns a 0, 

get_status_msgO 

The get_status_msgO function returns a string describing the current status flag value. The 
syntax is: 

s tring^name . ff«t_e t«.tus„inflg ( ) ; 

The function returns the string STR_ERR_OUT_OF^RANGE (set by putc) or 
STR_ERR_REGEXF_SYNTAX (set by match). 

substrO 

The substrO function returns the sub-string of characters between two specified locations. The 
syntax is: 

s trii3g_naine . subs t r ( i , j) ; 
i - The i parameter is the first location in the string. 
/ - The / parameter is the second location in the string. 

The function prints the characters between the locations, inclusively. If the second argument is 
omitted, the function returns all characters from the first location to the,end of the string. 

For example: 

string str, strl; ' ' * '* " 

fitr- = *ABCDEF'j . 

Etrl = str.sxibstr (2^ 4) ; ^ _ 

This example assigns string sfrl the value "CDE". 

3.4.4 String Class Methods for Matching Patterns 

Vera provides several class methods used to match patterns within strings. 
Syhopsyslnc. .-v. 
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searchO 

The search function searches for a pattern in the string and returns the integer index to the be- 
ginning of the pattern. The syntax is: 

string_naine, search (pat tern) ; 
pattern - The pattern parameter must be a string. 

The function returns the index value at the start of the string pattern. If the pattern is not 
found, the function returns -1. 

For example: 
integer i ; 

string str = "This is a test*; 
i = str .search <*his*) ; 

This example assigns the index 1 to integer u 
matchO 

The matchO function processes a regular expression pattern match. The syntax is: 

string_xiaine. match (pattern) ; 
pattern - The pattern parameter must be a string. 

The function returns a 1 if the expression is found, and a -1 if the expression is not foimd. If 
there is a syntax error in the regular expression, the function returns 0 and sets the status to 
STR_ERR_REGEXP„SYNTAX. 

For example: 

integer i; 
string str; 

str = *1234 is a number.'; 
i = str .match (*is'} ; 

This example assigns the value 1 to integer i because the pattern "is" exists within string str. 

The following functions (prematch, postmatch, thismatch, and backref) are used to access the 
match strings. 

prematchQ 

The prematchO function returns the string before a match, based on the result of the last 
matchO fimction call. The syntiax is: 

s tring_xiame . prematch ( ) ; 
For exsunple: 
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integer i ; 

string str, strl; 

str = *1234 is a number.*; 

i = str.inatch(*is') ; 

strl = str.prematchO ; 

This example assigns the value *1234 " to string strL 



postmatchQ 

The postmatchO function returns the string after a match, based on the result of flie last 
matchO function call. The syntax is: 

For example: 

integer i ; 

string str, strl; 

str = *1234 is a niunber.*; 

i = str,niatch(*is') ; 

strl = str .postmatchO ; 

This example assigns the value " a nximber/' to string strh 
thismatchQ 

The thismatchO function returns the matched string, based on the result of the last matchO 
function call. The syntax is: 

string_name.thLsmAtcU{) ; 
For example; 

integer i ; 

string str, strl; 

str = *1234 is a number.* 

i = str .match ( •is' ) ; 

strl = str.thismatchO ; 

This example assigns the value "is" to string strl, 
backrefO 

The backrefO function returns matched patterns, based on the last matchO function call. The 
syntax is: 

s tring^name, backref ( index) ; 

index - The index is the integer number of the Perl expression being matched. Indexing stsirts 
atO. 
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This function matches a string with Perl expressions specified in a second string. For example: 
integer i ; 

string str, patt, strl, str2; 

str - *1234 is a number.' 

patt = *([0-93+) {(a-zA-Z ,]+)'; 

i = s tr. match (patt ) ; 

strl = str.backref (0) ; 

str2 = str.bac3cref (1) ; 

This example checks the Perl expressions given by string patt with string str. It assigns the val- 
ue "1234" to string sfrl because of the match to the expression ''[0-9]+". It assigns the value "is 
a number," to string strl because of the match to the expression "[a-zA-Z .]+'', Any number of 
additional Perl expressions can be listed in the patt definition, and then called using sequential 
index numbers with the backrefO function. 

3.4.5 String Class Methods for Type Conversion 

Vera provides several class methods used for type conversion. 



atoiO 

The atoiO function handles a string as an ascii number and converts it to an integer. The sjm- 
tax is: 

£ tr ing^name . atoi { ) ; 

The string must be an ascii number. Underscores are ignored. Spaces and all characters other 
than digits are invalid. If the ascu string is not a number representation, the function returns 0. 

For example: 

integer i ; 
string str; 
str = *123'; 
i = str. atoi 0? 

This example converts the asdi text "123" and assigns the value 123 to integer u 
ItoaQ 

The itoaO function converts an integer to an asdi number in a string. The syntax is: 

s tring^name . Itoa { i ) ; 

I - The parameter i must be an integer. Underscores are ignored. All other characters are 
invalid. 

For example:. 
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string str; 
str.itoa(456) ; 

This example converts the numeric string value of 456 to ascii text and assigns the value "456" 
to string str. 

atohexQ 

The atohexO function handles a string as an ascii hexadecimal number and converts it to a bit 
value. The syntax is: 

s tring^name . atohex ( ) ; 

For example: 

bit [127:0] b; 
string str; 
str = *'hl2-; 
b = str.atohexO ; 

This example converts the ascii text value '"hlZ" to the hexadecimal number 'hl2 and assigns 
it to bit b. 

atooctO 

The atooctO function handles a string as an asdi octal number and converts it to a bit value. 
The syntax is: 

string^name. atooct ( ) ; 
For example: 

bit 1127:0] b; 
string str; 
str = -'012*; 
b = str. atooctO ; 

This example converts the asdi text value "'olZ" to the octal number 'ol2 and assigns it to bit 
atobinO 

The atobinO function handles a string as an asdi binary number and converts it to a bit value. 
The syntax is: 

s tring^name . atobin ( ) ; 
For example: 
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bit [127:03 b; 
string str; 
str = *'b01'; 
b = s tr . atobin ( ) ; 

This example converts the ascii text value '"bOl" to the binary number 'bOl and assigns it to 
bit 6, 

bittostrO 

The bittostrO function converts the text in bits to text in strings. The syntax is: 

string^name.hittoBtribitlhighzlow] bit_string) ; 

For example: 

bit [127:0] b; 
string str; 
b = •Hello*; 
str.bittostr (b) ; 

This example converts the bit string ''Hello" to a string and assigns the value 'Niello" to string 
str. 

3.4.6 Additional System Functions 

The following system functions are not part of the string class methods. They are independent 
functions that manipulate strings or are related to strings, 

sprintfQ 

The sprintf 0 system task sends output to a string variable. The syntax is: 

•printf {string_name, string^ format) ; 

The output specified by stringjormat is assigned to the string stringjname. 

For example: 

string SO; 
string str; 
SO = *S0 string'; 
sprintf (str, *S0 is %s\n', SO); 

This example assigns the string "SO is SO string" to string str. 
sscanfQ 

The sscanf 0 system task reads input from a string. The syntax is: 
flccanf ( s tring_name , s tring_ forma t ) ; 
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The input specified by string Jormat is assigned to the string string jmme. 

For example: 

string si; 

int il, i2, 13; 

sl = * 123 'hlO 4567*; 

sscanf(sl. * %d %h %2d', il, i2, 13); 

This example assigns the values 123, 16, and 45 to the variables il, i2, and i3 respectively. 

3.5 Enumerated Types 

Enumerated types are a user-defined list of named integer constants- As disctissed in 
Section 3.2.6, the syntax to declare an enumerated type is: 

enum category = list; 

So, for example, we could have: 

enum colors = red, green, blue, yellow, white, black; • 

This operation assigiis a unique number to each of the color identifiers and allows iis to create 
a new data type of type "colors.'' 

colors new_color; 
integer val; 

new_color = green; 

new_color = 1; // Invalid assignment. 

This example assigns the color green to the colors variable newjcolor. The second assignment is 
invalid because of the strict typing rules used by enumerated tj^jes. 

Elements within enumerated type definitions are assigned identifiers, which are numbered 
consecutively, starting from 0. In our example, red is assigned 0, green is assigned 1, and so 
on. 

I- ' . ' - , , / 

' You can further specify identifiers in tiie element list in several ways: 

• name This associates the next consecutive integer with name, 

• ,namc[N] This generates N names in the sequence (nameO, namel, 

nameN-1) where N must be a constant integer, 

• nameln.-ml This creates a sequence of names starting with namen and 

counting up (or down) to namem. 

• name=N This assigns ti\e constant N to name. 

For example: 

enum instructions = add=10, s\ib[53, jn^t6:83; 
Synopsyslnc. 
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This example assigns the number 10 to the enumerated type add. It also creates the enumerat- 
ed types subO, subh subl, sub3, and sub4, and assigns them the values 0-4 respectively. Finally, 
the example also creates the enumerated types jmp6, jmp7, and jmp8, and assigns them the val- 
ues 6-8 respectively. 



3.5.1 Enumerated Types in Numerical Expressions 

Elem^ts of an enumerated type or an enimierated type variable can be used in numerical ex- 
pressions. The value used in the expression is the numerical value assigned to the enumerated 
type element For excimple: 

colors new_color; 
integer vail, val2; 



vail = blue * 3; 

new_color = yellow; 

val2 = new_color + green; 

From our previous declaration, blue has a numerical identifier of 2. This example assigns vail 
a value of 6 (2*3), This example then assigns val2 a value of 5 (2+3). 



Note - Assignments to enumerated type variables are strongly typed. 
Thus, assigning numerical expressions to entimerated type variables 
causes compilation errors. 



3.5.2 Increment and Decrement Operations on Enumerated Types 

The operators ++, +=, and -= have special meanings on enumerated type variables. 

enum var -H- Assigns the next member (as defined by the definition order) to 

enum_van The first member is selected if enumjoar is currently holding 
the last member. 



enumjoar— 



enum var += val 



enumjoar val 



Assigns ttie previous member (as defined by the definition order) to 
enumjoar. The last member is selected if enumjoar is currently holding 
the first member. 

Assigns the val-th next member to enumjoar. A wrap to the beginning 
of the list occurs when the end of the list is reached. 

Assigns liie val-th previous member to enumjoar. A wrap to the end 
of the list occurs when the beginning of the list is reached. 
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Note - "mumjoar += valf is different than "enumjoar - enumjoar + 
vol;" The former is legal while the latter is illegal because '^enumjoar + 
val" is evaluated to a numerical expression which, in turn, cannot be 
assigned to an enumerated type variable. 

3-6 Vera Operators 

Vera uses a set of standard operators for expressions and concatenation. 

3.6.1 Operators 

Table 3-8 lists the basic Vera operators. 



Table 3-8 Vera Operators 



Operator 


Semantics 


{} 


concatenation 


'{} 


concatenation left of assignment 


+ -*/ 


arithmetic 


% 


modulus 


>>=<<:= 


relational 


t 


logical negation 




logical and 


1 1 


logical or 




logical equality 


!= 


logical inequality 




case equality 




case inequality 


=?= 


wild equality 


17= 


wild inequality 




bit wise negation 


& 


bit wise and 




bit wise nand 


1 


bit wise or 


!- 


bit wise nor 


A 


bit wise exclusive or 
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Operator Semantics (Continued) 

bit wise exclusive nor 

& unary and 

unary nand 

i unary or 

- 1 unary nor 

^ unary exclusive or 

-'^ unary exclusive nor 

« left shift 

» right shift 

?: conditiorval 



The conditional operator (?:) and the comparison operators ~, 1=, and !== can be used to 
compare variables of the same type for all base types. 

The wild equality operator {=?=) treats an x value or z value in a given bit position (for bit val- 
ues) as a wildcard. It matches any bit value (fl, 1, z, or x) in the value of the expression being 
compared against it. Consider the following vector and some comparisons against it: 

a = 8'bOOllOlOl 

(a =?= 8'bOOllOlOl) is tirue 
(a =?= 8'bOOOlOlOl) is false 
(a =?= 8'bOOxlOlOl) is true 

The same rule applies to the wild inequality operator(!?=). 

The precedence order of binary operators is defined in Table 3-9. 

Table 3-9 Precedence Order of Binary Operators 

Operator 

*/% 
•f - 

« » 
<<=>>= 

__ f_ f__ n 
&&- 

A A_ 



Precedence 

Highest precedence 
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Operator 


Precedence 


1 1- 




1 i 




?: 


Lowest precedence 



3.6.2 Concatenation 

The syntax for concatenation is: 

variahle = {varl, var2, varN)/ 
Variable is the result of the concatenation. The arguments are concatenated sequentially. 

For example: 

bit [6:0] data; 

bit parity; 

bit [7:0] foo; 

foo = {data, parity}; 

Multiple concatenation is also supported. For example: 

{ 32 {I'bl } } 
{ 4 {foo, moo} } 

This example concatenates /ao and moo four times. 

Vera uses the left brace to open a block and also for concatenatiorv This creates a coriflict when 
using the left brace for concatenation on the left-hand side of assignments. Therefore, Vera 
uses a single quote to prefix the left brace when it is used for concatenation on the left For ex- 
ample: 

'{ data, pac)cet, parity} = 256 'bO; 

3.7 Variable Assignment 

The variable assignment is the primitive operation to set a value for a variable. The syntax Ifco 
assign values to variables is: 

variable^name operator assign^Gxpression 

For example: 
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i = 0; 
a = I'bO 

teir^[3:03 = 4'blOOO; 
memory [53] = 8'bOxOxOxOx; 
b_port = portid ? portO : portl; 

There are two types of assign operators: the = operator is called the simple assignment opera- 
tor; all others are called compound assignment operators. 

For the compound assignment operator, the expression a <operator>= b is eqmvalent to 
a = a <operator> b. 

For example, the following are equivalent 

i = i + 5; 
i += 5; 

Vera supports the C-style ++ and — operators. For example: 

result = 5; 
a = result++; 
a = ++result; 

The second line accesses the variable and then increments in. The third line increments the 
Vciriable and then accesses it. 

Vera does not support assignment recursion. The following is an illegal assignment 
a = b = c; 

The Vera compiler does type checking. Bind.var variables can be used in simple assignments 
through the assigiunent operator, can be used in conditional assignments (?:), or can be passed 
as argimients. Event variables cannot be used in assignments because they are xised only for 
triggering purposes. All other combinations of integer and bit variables are valid. 

Note - To help avoid mistakes, <assignments> are not expressions. 
Hence, statements like the following are invalid: 

if (a=b) a=c+d; // should be a==b 

while (a=b) a=random{); // should be a~b 



SynopsyfTlnc. 



Vera 4.0 User's Manual 



Chapter 4. Basic Vera Programming 65 



4. Basic Vera Programming 

This ch^tcr documents the basic elements of Vera programming. It details the fundamental program 
* structure used in all Vera programs, introduces signal interfaces, and describes several of the elementairy 
signal operations. This chapter includes these sections: 

• Vera Programming Overview 

• Program Structure 

• Signal Declarations 

• Signal Operation 

• Asynchronous Operations 

• Subroutines 



4.1 Vera Programming Overview 

Vera programming involves the integration of several key components of a Vera tcstbench: the main 
Vera program, the Vera-HDL interface, the clocking mechanisms, signal operations, and Vera subrou- 
tines. 

The main V^a program is where global variables are defined, executable statements are carried out, and 
calls to subroutines are made. The main Vera program is the centerpiece of the Vera tcstbench. 

The Vera-HDL interface defines how Vera interacts with the hardware description created in cither Ver- 
ilog or VHDL. It establishes how the HDL signals arc driven and sampled by Vera. 

The clocking mechanisms determine the timing of the HDL signals. This directly affects signal driving 
and sampling. The clocks also determine timing for Vera processes, which affects synchronization of 
concurrent threads. 

The signal operations include the driving and sampling primitives in the Vera language. They handle 
sampling and driving of signals. Other fundamental signal operators include the expect primifive and 
synchronization. 

Vera can call subroutines (tasks and functions) from the main Vera program and from within subrou- 
tines. These subroutines include pre-defined tasks and functions as well as user-defined tasks and func- 
tions. 
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4.2 Program Structure 



Vera programs have a single, top-level structure denoted by the keyword program. The syntax is: 

finclude <vera_def ines.vrh> 
tine Xude * f i i ename ' 
idefine text_macro 
ipreprocessor cowmands 

signal^declara ti ons ; 
coverage^bl ocks ; 

externa l_si2JDrou tine_declarati ons ; 

subroutines; 

classes; 

HDL_and_C_subroutines ; 

program program^name 
{ 

variahl e_decl ara ti on ; 
top^l evel_code; 



The top block contains tasks, procedures, and function definitions. Vera, like C, supports two levels of 
hierarchy; top (containing the program statement) and others. Variables defined in the top block arc 
global and are seen in any task/procedurc/function anywhere in the entire set of tcstbench files (unless 
the same name is used to define a local variable). Using same named variables is called "shadowing" 
and should be used with caution because of variable conflicts that can arise. 

The syntax of a complete Vera testbench is flexible. It has one program and any number of submodules 
in any orden Forward references are allowed in any file. However, references to tasks or functions in 
other files require external references to be declared. The compiler accepts task and function declara- - 
tions before and after the top program. 

-Submodules, declarations, and external declarations are discussed in more detail in subsequent chapters. 
Note, however, that they can be used in any order. 

File inclusion, text macros, and preprocessor commands arc discussed in Section 18,2, **Preproccssor.*' 
Coverage blocks are discussed in ChdpXer 11^ *Tunctional Coverage,*' Classes are discussed in 
Section 8.1, "Classes and Objects.*' HDL and C/C++ subroutines are discussed in Chapter 14, **Vera- 
HDL Task Calls" and Chapter 15, *X::alling C/C++ Functions,"* 

The other major components of the main Vera program are discussed in detail in subsequent sections in 



} 



this ch^ter. 
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4.3 Signal Declarations 

Vera signal declarations determine how Vera teslbcnches are connected to HDL designs. There are three; 
methods of signal declaration: Vera-HDL interface specifications, virtual port definitions, and signal 
binds* 

4.3.1 Vera-HDL Interface Specifications 

The Vera-HDL interface identifies a set of signals through \rfuch Vera communicates with the HDL cn- 
viromnenL The interface also determines how Vera drives and samples those signals. Finally, the inter- 
face defines the clock to which the signals are tied. The syntax for interface specifications is: 

interface interfa.ce^name { 

signal^direction signal^width signal^name signal_type sJtev; 

} 

signalJLirection - The signal jiirection specifies the direction of the signal with respect to Vera. 
It must be input, which specifies signals that go from the HDL to Vera, output, which specifies 
signals that go from Vera to the HDL, or inout, which specifies bidirectional signals, 

signal_width • The signal_width is a bit vector specifying the width of the signal. It must be in the fonn 
[highiQl 

signaljname - The signal_name identifies the signal being defined. It is the top-level name of the HDL 
signal being connected. 

signaljype - The valid signal types and their definitions are listed in Table 4-L 



Table 4^1 


Signal types 


Signal Type 


Operation 


NHOLD 


Output is driven on the negative edge of the interface clock. 


PHOLD 


Output is driven on the positive edge of the interface clock. 


value 


OuQjut is driven on the falling edge of the interface clock for I cycle. 




Then it returns to value, which can be 0, 1, X, or Z. 


value 


Output is driven on the rising edge of the interface clock for 1 cycle. 




Then it returns to value, which can be 0, 1, X, or Z. 


NSAMPLE 


Input is sampled (evaluated) at the negative edge of the interface clock. 


PSAMPLE 


Input is sampled (evaluated) at the positive edge of the interface clock. 


ax>cK 


Specifies the clock, which qualifies other interface signals. 



For one-direction signals, only one signal type can be used. Input signals are sampled, and output 
signals are driven. Multiple signal types should be associated with bidirectional sigtials. 

skew - The skew detOTnines how long before or afio" the clock edge the signal is driven or sampled. 
The skew must be in this format: 
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# value 

All drives are done at or after the appropriate clock edge (positive skew). This means that drives 
can only take positive skew values. All sampling is done at or before the appropriate clock edge 
(negative skew). This means that samples can only take negative skew values. This limitation so 
that causality is not violated; it is impossible to sample a signal, use the value to determine a drive, 
and then drive a signal on a single clock edge. 



Note - To avoid race conditions, you should use a skew of at least -1 for all 
signal sampling. 



Figure 4-1 shows an example of positive and negative skews. 









15 -10 

J L 




-20 
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[sample] [drive] [sample] [drive] 



Figure 4-1 Example of positive and negative skews 

This is an example interface declaration: 

interface axb { 

output [1:0] request PHOLD #1; 
input [1:0] grant PSAMPLE #-1; 
inout (7:03 data PSAMPLE #-1 PHOLD #1; 



4.3.1.1 HDL Nodes 

HDL nodes allow you to bind a Vera port direcdy with a wire or port in an HDL design. The syntax to 
declare an HDL node is: 

signal_direction sigmil^name signal^type skew jiode_method *SigziaI_pati3' ; 

nod€_m€thod - The node^method specifies the type of HDL design you are linking to. It must be either 
verilog_iiode, which links to Verilog designs, or vhdl_node, which links to VHDL designs. 

signal ^path - The signcd^jxjuh is the HDL path to the specified signal. It must be surrounded by double 
quotes. - - 

— -lib-* 
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Note " VHDL nodes do not support signal subfielding. 



For example: 

incut [31:0] Dl PSAMPLE verilog_node •sys.cpu2 .pO_Dl* ; 
output req PS AMPLE vhdl^node "/sys/arb/pO.strb" ; 

Note the preceding slash and the use of slashes in the vhdl^node construct to specify the liierarchal 
path. 

When HDL nodes are used, the interface signals are declared as internal wires in the Vera-HDL shell 
(yera^shell) and are directly connected to the specified HDL node. If all the signals arc declared using 
the node construct, the verajshell module has no input or ou^ut signals. It can then be included asi a 
top module with the HDL design. As long as the interface does not change, the resulting verajshell- 
HDL module can be used with different test benches without rcdeclaring the signals, 

4.3.1.2 Clocking Domains 

Each interface defines a clock domain. The syntax to define a clock domain within Ac interface speci- 
fication is: 

input clock_naine CLOCK; 

clock_name - The clock_name is the name of the HDL clock driving the simulation. 

The clock domain specifies when clock edges occur and determines when signals are driven and sjun- 
pled. 

For a given interface specification, a clock domain establishes a relationship between the clock and 
when the other given interface signals are driven or sampled, 

Qock domains can be overls^ped. The same signal can be associated with multiple clocks via multiple 
interface specifications. However, despite multiple interfaces, it is still a single signal and cannot t>e 
driven to two values at the same time, 

4.3.1.3 Signal Depth 

Input signals are typically signalled in the current cycle. However, input signals can be sampled in pre- 
vious cycles. To reference a signal in a previous cycle, the signal depth must be specified in the signal 
declaration. The syntax to specify the signal depth is: 

signaljdirection signal jaame sign&l^type skew depth value; 

value - The value specifies the number of cycles that arc stored for back-reference. If you want to 
reference a signal 3 cycles back, this value must be at least 3. The value must be an integer. 

For example: ^ : ' - - j _ 
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inout [7:0] data PSAMPLE PHOLD #1 depth 5; 
The syntax to reference a signal in a previous cycle is: 

Inter face^name , sigfnal^neune . N 
mterface^name - The interface jname is the name of the interface in which the signal is defined, 
signal_nam€ - The signaljtame is the name of the signal being referenced. 

N-N specifies how many previous cycles to look back when evaluating the signal. The current cycle is 
0, the previous cycle is 1, and so on. If no signal depth is specified, the default is the current cycle, 

4.3.2 Virtual Ports 

Virtual ports are sets of port signal names grouped together under a given name. Ports are defined out- 
side of the main program block. The syntax to define a virtual port is: 

port port_name iport_signall7 port^signal2; — ; partes ignalN; } 
port_name - The port_name is the name of the virtual port you are creating. 

port^signalN - Port_signalN is a generic signal name that is assigned a specific HDL signal through a 
bind declaration. Multiple port signal names are separated by semi-colons {;), 

Virtual ports define a set of signal placeholders through generic signal names. The signal names must 
then be bound to the actual signals in the interface using a bind declaration. 

This is an example port declaration: 

port rcv_port {f raine_n;valid_n ; busy; packet ; } 

4.3.3 Bind 

Binds tic virtual ports to actual interface signals. Binds arc declared outside of the main program blocL 
The syntax to declare a bind is: 

bind port^name bind_najne { 

port^signalN in tGrface^name . signal^name ; 

} 

port^name - The portjname is the virtual port name you want to bind. 

bindjname - The bind^name is the name of the bind you arc creating, 

port^signdljuzme - The port^signalN is the name of the generic signal names that you arc 

including in the bind. Generally, all of the signals in the port are bound. However, you can bind 
only selected signals if you want 

inierface^name - The inierfacejname is the name of the interface to which you are binding the port 
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signal_name - The signal jname is the name of the signal you arc binding to the port. You can specify 
signal subfields using signa!_name[x:y]. 

Each bind in Vera is unique, and Vera assigns it a numeric ID. The bind can then be referred to by the 
name of the bind or by the numeric ID (obtained using the gct_bind_idO system function). 

When using subfield binding, you can specify fiirther subfields. For example: 

bind prt inybind{ 
a intf .sign [7:53 ; 
} 

This example assigns a 3bit subfield to the port signal a. You can specify a subfield within that field as 
well: 

mybind,$aI2:l] 

This signal refers to the subfield in signal a, which corresponds to intf . sign[7:6]. 
This is an example bind using the port declaration from the previous section: 

bind rcv_port iportO{ 

f rame„n rou ter - f raine_nO ; 
valid„n router .valid_nO ; 
busy router ,busy„nO; 
packet router. diO; 

} 

4.3.3.1 Bind Functions and Tasks 

Vera provides several system tasks and functions used with binds, 

get^bindO • ^ . » — : - , 

The get_bindO system function returns the current binding in a task or function. The syntax is: 

g^tJbUidilXDl) : 

ID - Hie ID can be either a numeric ID (obtained using the gct_bind_idO system function), or it can be 
the string name of the bind. 

The get.bind.idO system function returns the bind with the specified ID« If no argument is passed, ithe 
bind in the current system task is recuraed. If no match is found, a NULL value is returned. 

For example: 

task handshake (bindLvar iport, bit direction, bit my^data) 
{ 

drive_dat:^(get_bind() , direction, my^data) ; 

} 
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This example declares the task handshake, which is passed three arguments when it is called, includ- 
ing a bind. Tlie task then calls the function drive_data and passes the current bind and two other ar- 
guments when it is called. This ensures that the function drive_data operates on the same port that 
handshake uses. 

get.bindJdO 

The get_bind JdO system function returns the unique ID number for a given bind. The syntax is: 

gct_bind„id (i>ind_expressiozi) ; 

bindjexpression - The bind_expression can be a bind name, a bind variable, a port variable, or any 
• expression that returns a bind (such as get^bindQ). If it is not specified, the current bind ID is 
returned. 

For example: 

task handshake (bind_var iport, bit direction, bit jny_data) 
{ 

X = get_bind_id() ; 

drive_data(get_bind(x) , direction, iny_data) ; 

} 

This example gets the current bind ID and passes it to the get_bindO system function. Note that the 
variable jc must be declared as a bind_var. 

4.3.4 Using Ports and Binds 

The power of ports and binds comes form the ability to pass them as arguments to tasks and functions 
so that the tasks and functions work on the desired signals. This allows you to define generic tasks and 
functions, independent of the signals they act on. 

The use of ports and binds involves bind^yar and port variables. 

4.3.4.1 bind_var Variables 

Bind_var variables store binds. The syntax to declare a bind_var is: 
btnd_var variable_naine = initial^ value; 

Specific binds arc assigned to bind_vars. and the bind_vars arc passed as arguments to tasks and func- 
tions to specify which signals the tasks and functions operate on. For example: 

port myport (mysignall; mysignal2; my signals ) ; 



— ^ 
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bind inyport mybind { 

mysignall myinterface,signall; 
inysignal2 inyinterface,signal2; 
mysignal3 myinterface,sigiial3; 

} 

bind_var mybindvar; 
mybindvar = mybind; 

fxinction integer myf unction (bind_var testport) { 
} 

This code creates the virtual port niyport and binds it to the corresponding signals declared in my- 
interf ace. Tlien it declares the bind_var mybindvar. The code also defines the generic function nr^- 
function with the arguments testport L This line, within the main program module calls the function 
with the appropriate port: 

inyfxinction{znybindvar) ; 

This function call passes the bind_var mybindvar to the function so that the function operates on the (ie- 
sired signals. 

Bind_vars can be declared as arrays just as any other data type, 

Bind_vars can be assigned different binds, just like an integer variable can be assigned different values. 



Note - You must be careful when assigning new binds to bind.vars and 
passing them as arguments because any bind can be passed to any bind_v£tr. 
For example, if a function acts on 3 signals and you pass a bind with only 2 
signals, a runtime error will occur. There is no type checking to ensure that 
the right bind is being passed. 



4.3.4.2 Port Variables 

1' J 



Port variables store binds. The syntax to declare a port variable is: 

port_naine port^variable = xniCial_value; 

port^name - The port^name is the name of the port data type you arc referencing. 

port^variable - The port_variable is the name of the port variable you are .declaring. 

initial^value • The initial^value can be any existing port If it is not set, the portjvariable has a NULL 
value until it is assigned a port 

When a virtual port is declared, that virtual port becomes a new data type (much like an enumerated 
type). Variables of that type can then be declared and passed as arguments to generic functions and 
tasks much in the same way that bind_vats are. ^ 
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The key difference between port variables and bind^vars is that only binds of the port data type from 
which the port variable was declared can be passed to the port variable. For example: 

port myportl (niysignall;mysignal2 ; my signals ) ; 
port myport2 (mysignalA;mysignalB;inysignalC) ; 

bind myportl luybindl { 

mysignall my inter f ace. signall; 
mysignal2 myinterf ace* signal2 ; 
inys ignalS myinterf ace . s ignal3 ; 

} 

bind myport2 mybind2 { 

rnysignalA myinterf ace . signall ; 
mys ignalB myinterf ace , s ignal2 ; ' 
mysignalC myinterface,signal3 ; 

} 

myportl myportvar = mybindl; 

This code block creates the virtual ports myportl and inyport2, and binds the signals to the corre- 
sponding signals declared in myinterf ace. Then it declares the port variable myportvar of type 
myportl with the initial bind mybindl. 

A bind_var could be assigned the bind mybindl. However, assigning the bind mybindl to myportvar re- 
sults in an error because the port types arc not the same. 

Port variables can be declared as arrays just as any other data type. 



Note - Port variables provide a stricter method of type checking not afforded 
by bind_vars. For this reason, port variables are generally a preferred means 
of storing binds. 



4.3 A3 Direct Bind Signals 

Once a port and bind have been declared, bind signals can be referenced directly. The syntax to refer- 
ence a bind signal is: 

bind_or _por t^name , $signa J_name; 

bindjor jport^name - The bindjor _port_name is the name of the bind in which the signal is referenced 
or the name of the port variable that includes the bind. 

signal^name - The signal_name is the name of the signal as defined in the bind specified (either the 
direct bind specified or the bind with which the port variable is associated). 

For example: 

I>ort rcv„port {frame^nt packet} - 
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bind rcv_port iportO{ 

franie_n router . fraine_nO ; 
packet router. diO; 

} 

rcv_port port_val = iportO; 
rcv_port ports [3 Im- 
ports [11 = iport 0 ; 

router •fraiae_nO = 0; 
port_val.$frame„n = 0; 
ports 1 1 ] . $ f raiae„n = 0 ; 

This example declares the virtual port icv_port and creates the bind iportO. Then it declares the port 
variables port_val and ports[3], and assigns the bind iportO to port^val and ports[l]. The last 3 lines anj 
all Equivalent methods of referencing the same signal. 

4.3.5 Dynamic Binding 

Vent's dynamic binding capabilities allow you to connect to an HDL signal at runtime and change spe<:- 
ificd interfaces during the simulation based on external conditions. The dynamic binding capabilities in- 
clude void binds, runtime bind declaration, and runtime signal mapping. 

4.3.5.1 Void Binds 

Vera allows you to leave port signals unassigned using the void construct. The void declaration is made 
within the bind: 

port_signaI_naiiie void; 

Using the void construct creates a port signal that has no interface signal assigned to it Interface sig* 
nals can be assigned at runtime during the simulation. This is an example of a port and bind declaratic»n 
using void binds: 

port myportl 

'{ ' ' : ■ /, 

mysignall; 
znyslgnaX2 ; 

) 

bind inyportl mybindl { 

mysignall myinter face. signal 1; 
inysignal2 void; 

} 
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4.3.5.2 Runtime Bind Declaration 

Vera allows you to declare new binds at runtime by instantiating port variables. The syntax for runtime 
bind declarations is: 

port__name = new; 
port__name = now hij2d_name; 

portmame - The port_name is the name of the port variable being instantiated, 

bind_nam€ - The bindjname optionally specifies a bind of the same port type as the port variable, 
which specifies how the port signals are initially bound. 

The first construct instantiates the port variable. The port variable is local to the function it is instanti- 
ated in, or global if it is instantiated in the main program. The new port variable is of the same bind 
type as it was declared with all of the port signals unassigned. For example: 

task iny_task{) 
{ 

Myport portl, port2; 
portl=new; 

} 

This example instantiates the port variable portl, which will be of bind type Myport with each signal 
being assigned a void value. The resultant bind is: 

bind Myport portl 
{ 

signall void; 
signa.12 void/ 

sigzicilN void; 

sigrudN - The signals arc the port signal names specified in the original bind declaration Myport, 
Alternatively, you can optionally specify another bind of the same port type as the port variable: 

port__nam& = new blnd^namG; • 
This construct instantiates the port variable as a bind of the same type as the specified bind. 



Note - The specified bind and port variable must be of the same port type. 

For example: 

bind Myport Mybind 
{ 

signall valuel; 
signal2 value2 ; 



r 45 
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signalN valueN; 

} 

task iny^taskO 
{ 

Myport portl, port2; 
portl=new Mybind; 

) 

This example instantiates the port variable portly which will be of bind type Mybind, The resultant 
bind is: 

bind Myport portl 
{ 

sxgna.ll vaiuel; 
slgnal2 value2; 

sicfnalN valueN; 

} 

signalN - The signals are the signals specified in the original bind declaration Mybind. 
valueN - The signal values are the values as specified in the bind Mybind. ' - 

4.3.5.3 Runtime Signal Mapping 

Vera allows you to map port signals to HDL signals at runtime using the system function 
signal_conncctO. The syntax is: 

•Ignaljonnect {portjsignal , targe t^slgnal i , a ttribii tes I , ^ clockl 3 ) ; 

portjsignal - The portjsignal is the signal being mapped. It must be a port signal pf an insuatiated 
bind, 

targetjsignal - The target^signal is the new signal to which the portjsignal is {^apped. It can be a 
signal reference or a string specifying an HDL node. You can specify subfields mthin the 
targetjSignal ^ . , 
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attributes - The attributes optionally specify how the new connection is made. Multiple attributes can 
be assigned in any order. The attributes with possible values are listed in Table 4-2. 

Table 4-2 signal_connectO attributes and values 



Attribute 


Possible Vaiues 


dir 


input , output t or Inout 


width 


integer width of signal to connect (default 
is signal width on HDL side) 


itype 


NSAKFX£ or PSAKPI«E 


otype 


»HOrJ>, PORXVE, KDRXVE, NRO, NRl, KRX« 
NRZ, PRO, PRl, PRX, or PRZ 


depth 


0 or 1 (default is 0) 


iskew 


any non-positive integer (default is 0) 


oskew 


any non-negative integer (default is 0) 



This is an example string declaring signal attributes: 

*dir=input width=l itype=PSAMPLE iskew=-3- 
Note that the string is enc^sulated in double quotes C* The string is not case sensitive. 

If the target^signal is an HDL node, the attributes must specify at least a minimum complete set 
(direction and signal type). If the target _signal is a specific signal, the attributes simply modify the 
existing set of attributes for that signal. 

clock - The clock specifies the clock for any generated interfaces. It can be a reference to an interface 
signal, or it can be a string specifying a signal on the HDL side. Regardless, it must be a 1-bit 
signal (subfields are not allowed). If it is not specified, SystemClock is used. 

When the signaI„connectO system function is called, the port signal is connected to the target signal as 
specified. If the port signal was previously connected, that connection is lost when the call is made. The 
connection that is made when the function is called depends on how the call is made. 

Only port.s/flrna/ and far^geLs/^na/ are specified 

If only the port^signal and target_signal are specified, the port^signal is simply remapped to the 
targ€t_signaL The targetjsignal must be a signal reference. For example; 

Eignal_connect (portl , $b, df f . q) ; 
signal_connect (portl, $b, portl. $a) ; 
Eignal_connect (portl . $b $a) ; 

The first example connects signal b horn portl to signal df f . q. The second example connects signal 
b from portl to signal a from portl. The third example connects signal b from portl to signal a 
from the port with which the task (with port) is called. 
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targef_«/gna/ specifies an HDL node 

If the target^signal is a string specifying an HDL node, you MUST include the attributes. When the 
function call is made with the target jsignal specifying an HDL node, a new interface is created with the 
given attributes. The clock for the interface is either the clock specified in the function call or Sys- 
temClock if no clock is specified. All the signal interfaces are force driven by Vera at runtime. This 
drive overrides any HDL driving or static interface connections. 



Note - Using this configuration, you cannot connect multi-bit registers or 
portions of registers as output or incut signals. 



For example: 

signal_connect (portl . $b, * test_top . df f . q[3 ; 0 3 ' , **dir=input 
width=4 itype=PSAMPLE iskew=*3', dff.clk); 

This example creates a new interface with a single connection from the signal portl • $b to the HDL 
node specified by **test Jop.dff,q[3;0].*' On the DUT side, the signal has a width of 8 bits, but in this ex- 
ample only the 4 least significant bits arc connected. The signal has the specified attributes. The inter- 
face clock is df f -clk. 



Note - When using this signal.connectO configuration with Verilog-XL, you 
must use the *x switch at runtime. When using this configuration with VCS, 
you must compile the code with -P $VERA_HOME/lib/vcs_pli_dyn,tab. 



target^signa! specifies a signal and attributes or clock is specified 

If the targetjsignal specifies a signal or interface and either the attributes or clock (or both) is specifier!, 
a new interface is created. The signal is connected to the specified target and the new interface has thie 
given attributes and clock. This configuration for the signal.counectO call is useful for sampling thct 
same signal on different clock edges or with a different clock. By changing the attributes or assigning a 
new clock to the signal, you can sample the signal under varying conditions. If you need to sample tlie 
same signal with a different clock without changing any attributes, you can specify the attributes with 
an empty stringC* **). * r : T 



Note - When using this dgnal^coiinectO configuration with Verilog-XL, you 
must use the *x switch at runtime. When using this configuration mth VCS, 
you must compile the code with -P $VERA_HOME/lib/vcs_pli_dyii-tab, 



4.3.5.4 Dynamic Binding Example 

This is an example of bow dynamic binding is used: 
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port port_channel 
{ 

bus_a; 
bus_b; 

} // a port with just 2 bits 

task create^bindings 
( 

• var port_chaimel arr_binds[3r // destination assoc, array of ports 
integer how_inany_ports , // how many ports 

string sig_options, // signal options, e,g, •dir=input width=l 
string sig„clock // the clock to connect to, e.g. ■main^iaod.clk* 

) 
{ 

integer i; 
string verpath; 

for (i = 0; i < how_many_ports ; i++) 
{ 

arr„binds[i3 = new; // create a binding for this array index 
sprintf (verpath, •inain_mod.bus_aC%0d3 i) ; //generate path for bus^a 
signal_connect (arr_binds [i] . $bus„a, verpath, sig_options , sig_clock) ; 
sprintf (verpath, '■inain_mod.bus_b[%Od]-, i) ; //generate path for bus_b 
signal„connect(arr_binds(i3 .$bus_b, verpath, sig_options, sig_clock) ; 

} 

} 

This example creates an associative array of bindings of type port_channel, and assigns to them 
each bit of iriain_mod,bus„a and inain_mod . bus„b. Each element of the associative array is as- 
signed a difTercnt bit of bus_a and bus_b. Note the use of string expressions to specify the HDL path, 

4,4 Signal Operation 

Vera separates its timing and signal operations, which makes test development and maintenance easier 
to handle. The timing is defined in the intoface specification, which simpUfics signal operation in that 
the skew and clock are predefined. 

Vera provides four primitive statements that operate on interface signals: 

• Synchronization 

• Drive 

• Sample 

• Expect, 

Vera also provides a value change alert (VGA) for use with signals. 
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4.4-1 Synchronization 

The synchronization operator (@) is used to perform explicit synchronization. The syntax is: 
6 {clock_edge xnterface^signal) 7 

clock jedge - The clock jcdge optionally specifies the clock edge at which the synchronization occurs, jis 
defined in the interface declaration. It must be either negedge, which specifies a negative or falling 
clock edge, or posedge, which specifics a positive or rising clock edge. If no clock edge is 
specified, the synchronization occurs on the next change in the specified signal. 

uUerfacejiignal - The interface^signal specifies the signal to which the synchronization is linked It 
can be any defined signal or CLOCK, The interface signal can be any subfield of a signal as well. 
If a signal is not specified, the interface is clocked by Sys teraClock. 



Note - Only 1 bit signals can be synchronized on the posedge or negedge. 

If the interface signal is a subfield of a signal, the synchronization occurs on the first change of the sig- 
nal subfield. If the subfield is a I -bit subfield, you can synchronize on clock edges. If you spedfy vari- 
ables in the subfield. Vera evaluates the variables at runtime. 

You can use the OR keyword to specify multiple interface signals. If you specify more than one signal, 
the synchronization occurs on the next change of any of the listed signals. 

These are some example synchronization statements: 

e ( f oo_bus .ack_l ) ; 

e ( CLOCK ) ; 

©( posedge foo^bus . clock ); 

e( negedge intfc.signla:b] ) ; 

The first example synchronizes to the clock edge corresponding to the next change of the ack_l sig- 
nal, as declared in the f oo_bus interface specification. The second example synchronizes to the Sy s- 
temClock. The third example synchronizes to the positive edge of the interface clock. The last 
example synchronizes to the falling edge of the specified subfield. 

Note that at initialization, HDLs can create edges at time = 0 (for example, going firom X to the iini- 
tiaiized value). This means that synchronization conditions can be set before initialization of the sigiaal. 

4.4.2 Drive 

Drives set the value of output interface signals. The syntax to drive a signal is: 
delay signa.l_name range drxve^operator express ion; 

delay - The delay specifies the number of cycles that pass before the signal is driven. It is in the form 
@n where n is the number of cycles, 

sigrudjname * The signal^name is the name of the signal being driven. 
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range - The range specifies which bits of the signal are driven, If no range is specified, the entire 
signal is driven. 

drive ^operator - The drivejDperaior must be either =, which specifies a blocking drive, or <=. which 
specifies a non-blocking drive, 

expression - The expression can be any valid Vera expression. 

These arc some drive examples: 

foo„bus.data[3:03 = 4'h5; // blocking drive 
ei fooj3Us.data <= 8'hz; // non-blocking drive 

4.4.2.1 Blocking and Non-Blocking Drives 

There are two types of drives specified by the drive opcraton blocking and non-blocking. Blocking 
drives suspend Vera execution until the number of HDL cycles specified in the delay passes. Note that 
the specific time within the cycle that the drive unblocks is determined by the clock edge on which the 
drive takes place (NHOLD or PHOLD). Once the delay passes. Vera execution resumes. Non-blocking 
drives schedule the drive at a future cycle and Vera execution continues. When the specified cycle oc- 
curs, the drive is executed. 



Note - For performance reasons, input and output skews are implemented 
with delay buffers to minimize the amount of interaction of Vera widi the 
simulation. Unless you use the delayO system task or asynchronous signal 
operations. Vera only interacts with the simulation at clock edges. 

These are some blocking and non-blocking examples: 

63 f oo_bus . data = 1 ; 
a = b; 
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@3 foo_bus.data <- 1; 
a = b; 



foo_Jbus-data = 1 



f i 

a=b foo_biis.data = 1 

Hie first block is a blocking drive- Three cycles must pass before the second line is executed. The sec- 
ond block is a non-blocking drive. The drive is delayed three cycles. The second line is executed, and 
the simulation advanced three cycles before the first drive is executed. 

4.4.2.2 Strong and Soft Drives 

There are two strengths of drives: strong (default) and soft. The syntax to declare a soft drive is: 
delay signal^name range driye^operator expression soft; 

A given signal should only be driven by a single strong drive at any given time. Multiple strong drives 
at the same time result in conflicting drives. Conflicting strong drives drive the signal to X and result in 
a simulation error. However, conflicting soft drives can drive a signal to X without causing a sitnulation 
error. Finally, if a signal is driven by a conflicting strong and soft drive, the strong drive dominates and 
the signal is driven by the strong drive. 

4.4.2.3 Void Drives 

Drives block until the appropriate driving clock edge occurs. If you want to wait for this clock edge 
without actually driving the signal, use the void construct. The syntax is: 

delay signal^name = ▼oid; 

For example: 

©1 iportO. packet = void; 
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4.4.3 Sample 

Samples assign the value of a signal to a variable. The syntax is: 
variable ~ signal^name} 

The signal value can be an interface signal or a port signal, but it must be an input or inout signal. It is 
sampled at the next sampling point (specified in the interface file) and the value is assigned to the vari- 
able. It cannot be delayed like drives can. Remember that you can sample previous cycles using the sig- 
nal depth construct (see Section 4.3,1.3, "Signal Depth*'). Also remember that you can sample subfields 
within the signal by specifying a specific subficld in the signal width. 



Note - When you sample a signal in an expression, it is done immediately. 



4,4.4 Expect 

The expect event asserts that a given signal has a given value at a given time. There are several forms 
of the expect primitive: 

• Simple expect - @ 

• Full expect - @@ 

• Restricted - 

The general syntax for an expect statement is: 

expect_operator delay window expect^list; 

expectjopercUor - The expect ^operator must be cither @, which specifies a simple expect, @@, which 
specifies a full expect, or @@@, which specifies a restricted expect. Each form is discussed in 
detail in subsequent sections. 

delay • The delay specifies the number of cycles that pass before the signal is driven. It is in the form 
@n where n is the number of cycles, A delay must be specified. For immediate checking, use a 
delay value of 0 cycles, " ' 

window - The window specifies how long the check is made. It must be in the form ^ where n is the 
number of cycles for which the check is made. The comma (,) immediately follows the delay. Any 
expect with a defined window is called a floating expect, 

expect JUst - The expect Jist is any number of expressions (separated by commas) using the equal to 
(=) and not equal to (!=) operators. The bit value *X* is treated as a "don't care" in expressions. 
The general form is signal_name operator expression. Signal names can be interface or port 
signals, and they can include subfields. If multiple expressions arc declared, they are all sampled on 
the clock edge of the first signal in the list. 



Note - The expect primitive is a blocking primitive. It blocks until the expect 
is satisfied or a simulation error is generated. There is not a non*blocking 
form of the expect primitive. 
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4.4.4.1 Simple Expect 

The simple expect checks that a given signal has a specific value at a given time. The syntax is: 
e delay window expect_Iist; 

If the signal value does not match the expression when the check is made, a simulation error is gener- 
ated. If a subficld within the signal is specified, all other bits in the signal arc ignored and only those 
specified are checked against the expression. 

Multiple expressions can be defined in the expect JisL If multiple expressions are defined, the expect iis 
satisfied if ALL of the conditions are satisfied at the time of the sample. 

Expressions can also be separated by the or keyword. In that case, the expect is satisfied if any of the 
conditions is satisfied at the time of the check. 

Note - You cannot mix comma separated expression lists with or lists. 

If a window is specified, the expect is a floating expect Ihe check is made for the duration of the win- 
dow. If the signal value matches the expression at any time within the window, the expect is satisfied. 
If the signal value does not match the expression within the window, a simulation error is generated. If 
multiple expressions are defined, the expect is satisfied when all the conditions are satisfied simulta- 
neously. If the or keyword is used, the expect is satisfied as soon as any of the conditions is satisfied. 

These are some examples of the expect statement: 

ei bus.data[7:4] == 4'bOlOl; '-'"^ ' 

©0,10 bus, data 4'bxOxl; ... 
@1 bus. data == 4'baOlO. bus.addr != 4*b0001; 
%2,2Q bus, data 4'bOOlO, bus,addr 1= 4'bOOOl; 
©2,20 bus, data =^ 4'bOOlO or bus.addr == 4'bOOOl; 

The first example expects the signal data to be equal to 0101 after 1 cycle. 



The second example expects the signal data to be equal to 1011, 1001, 0011, or 0001 vnthin 10 cy- 
cles. ■ 

The third example expects the signal data to be 0010 and the signal addr not to be 0001 after 1 cycle. 

The fourth example expects the signal data to be 0010 and the signal addr not to be 0001 within 2 to 
20 cycles. 

The fifth example expects the signal data to be 0010 or the signal addr to be 0001 within 2 to 20 cy- 
cles. 



4.4.4.2 Full Expect 

FuU expects check that a signal has a given value over the entire length of a given interval. The syntax 
is: 

— ^» 
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TO delay window expect^list; 

Full expects behave in the same manner as simple expects with one exception. The signal value must 
match the expression over the entire course of the defined window. If the signal does not match during 
any part of the interval, the expect is not satisfied and a simulation error is generated. 

This is an example of a full expect statement: 

e@5,100 bus.data[7:43 != b'OlOl, bus.addr 8'h88; 

This example is satisfied if the signal data is not equal to 0101 and the signal addr is equal to 88 
over the entire interval, 5 to 100 cycles. 



4.4.4.3 Restricted Expect 

Restricted expects check that a signal*s value changes to a given value on the first signal change. The 
syntax is: 

6TO delay window expect^list-. 

Restricted expects check that the signal matches the expression on the first signal change within the 
window. If the signal value does not match the expression after the first signal change, a simulation er- 
ror is generated. If the signal value matches the expression at the start of the window, the expect is sat- 
isfied immediately. If multiple expressions are defined using an AND construct, all of the conditions 
must be satisfied at the time of the first change to any of the signals, or else a simulation error is gen- 
erated. 

These are some examples of restricted expects: 
&@@0,100 bus. addr 8'hOl; 

@@eO,100 bus. data == 8'h88, bus. addr ~- 8'hOl; 
The first example is satisfied if the first change of signal addr is to 01. 

The second example is satisfied if the first change of signal data is 88 and the signal addr changes to 
01 simultaneously (or if it is already 01), The second example is also satisfied if the first change of sig- 
nal addr is 01 and the signal data changes to 88 simultaneously (or if it is already 88). 



4.4.4.4 Strong and Soft Expects 

There are two strengths of expects: strong (default) and soft The syntax to declare a soft expect is: 

Gxpect^operator delay window expect_list soft; 

Soft expects do not generate simulation errors when they are not satisfied. Instead, they set an error fl^ 
and the simulation continues. You can check if an error flag has been set using the flagO system func- 
tion (see Section 73.1, **&ror Handling"). 

The soft keyword can be used with any of the expect pnmiuves. 

- ^ 
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AAA.5 Void Expects 

Expects are blocking in thai if the Vera thread thai executes them is not at the appropriate clock edge, it 
blocks until the appropriate clock edge occurs. If you want to wait until this clock edge without expect- 
ing the signal, use the void construcL The syntax is: 

0 del ay signal^name == void; 

For example: 

81 ipor to. packet == void; 

4,4.5 Value Change Alert (VGA) 

The value change alert (VGA) checks that no unexpected event occurs on a signal during the simula- 
tion. VCAs are declared within the interface specification. The syntax to declare a VGA is: 

siffzial^direction signal^width signal^name signal^type skew vca qu,va.lue: 

q_yalue - The q^value is the quiescent state of the signal. The valid q^values are listed in Table 4-3. 

Table 4-3 VCA q.valuc 



q_ value Definition 

rl Signal returns to 1 (pullup) 

rO Signal returns to 0 (pulldown) 

rz Signal returns to z (tri) 

rx Signal returns to x (forced or driven) 

nr Signal holds last value (all transitions are flagged) 

srl Signal returns to 1 (pullup) 

srO Signal retunis to 0 (pulldown) 

srz Signal returns to z (tri) 

srx Signal returns to x (forced or driven) > 

snr Signal holds last value (all transidons are flagged) • . r. n 

grl Signal returns to 1 (pullup) ■ ^ 

grO Signal returns to 0 (pulldown) 

grz Signal returns to z (tri) 

grx Signal returns to x (forced or driven) 

gnr Signal holds last value (all transidons arc flagged) 



The q_valu€ for a vector applies to all bits in the vector. Thus an 8-bil bus defined 

as rl has the qjfdiue 8'hff, rO would have a q_value 8*hO0, rz 8'hzz, rx 8'hxx, and nr would have 

a qjvalue equal to whatever Ac previous value was. 
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The q_values rl, rO, rz, rx, and nr are asynchronous detects and detect any asynchronous changes 
except zero-delay glitches. The q^values srl, srO, srz, srx, and snr are synchronous detects and only 
detect errors at synchronous clock edges. The q^values grl, grO, grz, grx, and gnr are glitch detects 
and detect all asynchronous changes including zero delay glitches. 

You only need to define q^values for those signals that have the VGA enabled for them. 

Note - The VGA cannot be used with output signals. 

This is an example of a signal declaration with the VGA specification: 
input b PSAMPLE depth 1 vca rz; 

Declaring a q_yalue in the interface specification docs not enable the VCA for a signal. By default, all 
signals are VGA-disabled. To enable and disable Uie VGA for a signal or interface, use the system task 
vcaO* 

vcaO 

The vcaO system task enables and disables VCAs. The syntax is: 
vca ( swi tch I , signal^namel ) ; 

switch - The switch must be either ON, which enables the VGA for the specified signal, or OFF, which 
disables the VCA for the specified signal. The default value is ON. 

signal_name • The signal jname can either be the name of an interface, which enables or disables all 
VCAs withm the interface, or it can be the name of an individual signal in the form 
interface^nameMgnal^name. 

This is an example of the vcaQ system task: 

vca (ON, itiyinterf ace) ; 

vca (OFF, myinterface.signall) ; 

When a VCA is enabled for a particular signal. Vera checks that all changes to signals are to the quies- 
cent state (q_value) unless there is a matching expect on the next sampling edge or the signal is explic- 
itly driven to the new state. 

After a change is made, the VCA does not drive the signal back to the quiescent state. To return the sig- 
nal to its quiescent state, you must explicitly drive it 

Note that for pipelined signals, VCA reports arc delayed. This is because Vera must first find out if 
there are any expects in the pipelined version of the signal that affect whether a value change is expect- 
ed or not So, Vera must wait until all of the cycles specified have been executed, and then it produces 
applicable VCAs. 

Note - VCAs arc implemented such that they do not slow down the 
simulation in any significant 'way, ' 
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4.4.6 Implicit Synchronization 

The drive, sample, and expect primitives perform implicit synchronization to the interface CLOCK, 
That means that the clock is advanced only when it is necessary to perform the next signal operation. 
Take the following interface definition as an example: 

interface foobus { 

output reset_l NHOLD; 
input strobe_l PSAMPLE; 
output ack_l NHOLD; 
inout data PSAMPLE NHOLD; 
input clock CLOCK; 

} 

In this interface, output signals are driven at the negative edge of the interface clock, and input signals 
are sampled at the positive edge of the interface clock. Thus, the following code advances the simula- 
tion cycle a half cycle per statement even though a delay is not specified. 

reset_l = I'bl; 
strobe_l == I'bl; 
ack_l ^ I'bO; 
strobej == I'bO; 

The first signal is driven on the negative clock edge. The second signal is sampled on the positive clock 
edge. The third signal is driven on the negative clock edge. The fourth signal is sampled on the positive 
clock edge. 

The description gets more complicated when delay values are used to generate proper timing witii re- 
spect to different edges. To avoid this, use the same edge for inputs and ouQ)uts, witii appropriate output 
skews. For example: 

interface foobus { 

output reset_l PHOLD #2; 
input strobe_l PSAMPLE; 
output ack.l PHOLD #2; 
inout data ^SAMPLE PHOLD #2; 
input clock CLOCK; 

} 

4.5 Asynchronous Operations 

By default, drives, samples, and expects are relative to a clock edge (specified in the interface specifi- 
cation). However, the HDL side of the simulation may be using very detailed timing constructs. Vera 
provides the async and delay constructs to allow detailed timing down to the HDL timcstep. 
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4.5.1 async 

The async optional modifier specifies that the operation happen immediately, without waiting for the 
edge specified in the interface. It can be used with synchronization operators, drives, samples, and ex- 
pects. The syntax is: 

Sync: € {signal^name async) ; 

Drive: signal^name range drive_operator expression async; 

Sample: variable = signal_najae async; 

Bxpect:: 6 expect^list async; 

The synchronization construct allows you to act exactly on the specified edge rather than waiting for 
the corresponding sampling edge. 

The drive, sample, and expect constructs force the operation immediately instead of waiting for the 
specified edge. 

Note - Drive skews specified for the signal in the interface specification also 
apply to async drives. If you need to drive the signal precisely when the drive 
is issued, do not specify any skew for that signal in the interface 
specification. 

If a signal has a VGA enabled for it, driving it with the async option results in a VGA error. Disable 
any active VCAs when driving signals asynchronously. 

These are examples of async statements: 

@ (posedge inain_bus , reqrviest async) 
memsys,data[3;0] = 4'blOlO async; 
data [2:0] = main_bus •dataI2 :0} async; 
einain_bus.data[7:43 ^= 4'bOlOl async; 

4.5.2 Sub-Cycle Delays 

Vera provides the ddayO system task to block Vera while a specified amount of time elapses on the 
HDL side of the simulation. The syntax for the dclayO system task is: 

delay (time) ; 

time - The time specifies the length of the delay. It is in the same timing units being used by the HDL, 
This is an example of the delayO system task: 

e (posedge CLOCK) ; 
delay (5) ; 
functionl () ; 
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This example synchronizes to the positive edge of CLOCK, Then it advances the simulation time 5 time 
ticks. Functionl executes 5ns after the clock edge. 



Note - This does not work with Vera-CS because there is no HDL design 
generating a clock. 



4.6 Subroutines 

Vera supports two means of encapsulating often-executed program fragments: functions and tasks. All 
functions and tasks are re-entrant and can be called recursively. 

Vera subroutines cannot be nested. This means that all subroutine declarations must be done at the top 
level. To ease the name space problem. Vera supports local subroutines and separate compilation. You 
can also declare external subroutines. These separately compiled Vera object files are linked at simula- 
tion time (see Section 18.6, "Modular Ck)mpilation"). 

4.6,1 Functions 

Functions are provided for implementing mathematical functions containing some number of arguments 
and one return value. Functions can be used in expressions in order to perform frequently used calcula- 
tions, or to encapsulate the calculation. The syntax to declare a function is: 

function data^type function^naiae {arguments) {statements;) 

datatype - The datajtype can be any of the valid Vera data types. The value retitmcd will be of the 
same data type that the function is declared with. 

funcdonjtame - The function^name is the name by which the function is called throughout the 
program. 

arguments - The arguments are the variables, including the data types, that are passed to the function 
when the function is called All data types can be passed, including ports. Array arguments can be 
regular or associative, as well as var. Array aiguments are strongly typed. Array type, width, and 
size must match exactly between the declaration and the call. Multiple argimients arc separated by 
commas. 

statements - The statements can be any Vera statement, including function calls, timing modifiers, and 
variable assignments. 

Functions are designed to return a single value. They can return values of any data type as well as data 
structures. To set the return value, assign the name of the function a value somewhere within the func- 
tion declaration. 

This is an example function declaration: 
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function bit [3:0] even_byte_parity (bit [31:0] data) 
{ 

bit [3:0] tir^; 

t:inpr3] = MataE31:243 ; 
tmpf23 = '^data[23:16]; 
tmpCl] = -"data [15: 8] ; 
tinpIO] = '"dataf 7: 0] ; 
even_byte_paritY = tmp; 

} 

This example declares the function even_byte_j>arity with the argument data. Note the final line 
of the function, which contains the line that sets the return value. 

Functions can be called in expressions from within the main program or from within other functions. 
The syntax to call a function is: 

variable = function { arguments) ^ 

For example: 

parity = even_byte_parity (Data) ; 

By default, function names are global. Functions declared as local can only be used in the file where 
they are defined. To invoke a function defined in another file, you must use the extern declaration (see 
Section 4.6.7, '^External Definitions"). The syntax to declare a local function is: 

local function data_t>pe jfunction_name {arguments) {statemants; ) 
For example: 

local function bit[3:0] g_decode ( integer i ); 



4.6-1 .1 Discarding Function Return Values 

Vera enforces the use of function return values. Calling a function as if it has no return value results in 
compilation errors. To explicitly discard a function's return value, use the void construct The syntax is: 

void = Jfunction(argiiraents) ; 

4.6.2 Tasks 

Tasks are identical to functions except they do not return a value. The syntax to declare a task is: 
t«.flk task^name {arguments) {statements}} 

task_name - The taskjname is the name by which the task is called throughout the 
program. 
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arguments - The arguments arc the variables, including the data types, that are passed to the function 
when the function is called. All data types can be passed, including ports. Array arguments can be 
regular or associative, as well as var. Array arguments are strongly typed. Array type, width, and 
size must match exactly between the declaration and the call. Multiple arguments are separated by 
commas. 

statements - The statements can be any Vera statement, including function calls, timing modifiers, and 
variable assignments. 

This is an example task declaration: 

task handshake_portO (bit direction, bit 17:0] data) 
{ 

©0,1000 portO.req == I'bl; 

portO.ack = l*bl; 

ei portCack <= I'bO; 

if (direction) portO.data = data; 

else portO.data == data; 

} 

Tasks can be invoked as statements. The syntax to invoke a task is: 
task_name{ arguments) ; 

For example: 

print_data(new_data) ; 

By default, task names are global. Tasks declared as local can only be used in the file where they ane^ 
defined. To invoke a task defined in another file, you must use the extern declaration (see 
Section 4,6.7, *TBxtemaI Definitions"). The syntax to declare a local task is; 

local task task^name {arguments} {statements; } 
For example: 

local task print_data (bit [7:0] data) 
{ 

printf ( *Local data = %h'', data); 

} 

4.6.3 Return 

Normally, functions and tasks return control to the caller after the last statement of the block is cxe<:ut- 
cd. Vera provides the return statement to manually pass control back to the caller. The syntax is: 

return; 
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When the return statcmeni is executed, the subprocess is terminated as if it had been exited normally. 
If the return statement is executed in a function before a value has been assigned, an undefined value 
is returned. 

If a return statement is executed at the top code level, the simulation is terminated. 



4.6.4 Breakpoint 

Vera provides the breakpoint statement to stop the simulation and return control to the HDL. The syn* 
tax is: 

fareaJcpol&t ; 

When a breakpoint statement is executed. Vera terminates the task or function immediately and returns 
control to the HDL, You must restart the simulation from the HDL command line. Simulation time con- 
Unues while the process is terminated. So be careful when using breakpoints because the simulation 
time is not handled precisely on restart. 

If a breakpoint statement is executed at the top code level, the simulation is terminated. 
When a breakpoint statement is executed, the Vera debugger is launched. 

4-6.5 Static Variables 

By default, variables are local to the function or task that uses them. They are allocated when the func- 
tion or task is called. This construct allows tasks and functions to be re-entrant and recursive. 

If you want a variable to be shared across all invocations of a function or task, use the static declara- 
tion. The syntax to declare a static variable is: 

»tatic data_type variable^name; 
Any data type can be declared as a static variable. 

Note - In the case of concurrent accesses, there may be races if multiple 
threads assign to the same static variable. 



4,6.6 Subroutine Arguments 



Vera provides two means of accessing arguments in functions and tasks: "call by value** and "call by 
reference." 
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4.6.6.1 Call by Value 

"Call by value*' is tlie default method that arguments are accessed in functions and tasks. Each subrou- 
tine retains a local copy of the argument If the arguments are changed within the subroutine, the chang- 
es do not affect the caller. 

4.6.6.2 Call by Reference 

In a "call by reference/' functions and tasks access the specified variables passed as arguments directly. 
The syntax to pass a subroutine argument by reference is: 

sxj±>routine (var data^type variable) ; 

In a "call by reference/' subroutines operate directly on the var arguments. The caller sees any changes 
to variables made within the subroutine. Variables of any type can be passed by reference. 

This is an example of a "call by reference": 

task IO_read_indirect ( bit[63:0] addr, var bit [31:03 io_data ) 
{ 

// (modifies both addr and io_data) 

// ... (only the change in io_data will be seen by caller) 

} 

// caller 

IO_read_indirect (iny_addr, 2ny_data ) ; 

In this example, the variable iojdata is passed by reference. The task modifies all of the arguments 
passed, but only the change made to iojiata is seen outside the task- 

4.6.6.3 Default Arguments 

To handle common cases or allow for unused arguments. Vera allows you to define default values for 
each scalar argument The syntax to declare a default argument in a subroutine is: 

subroutine (argsdefault_value) { statements} 

defaub_valu€ - The defaultjvalue can be any expression visible at the current code level. It can include 
any combination of constants, global variables, and functions. 

When the subroutine is called, you can omit an argmnent that has a default defined for it Use an aster- 
isk (*) as a placeholder in the subroutine call. If an asterisk is used for a variable that does not have a 
default value, a compilation error occurs. 

This is an example of a subroutine with default arguments: 

task footinteger i = 0, integer k, bitt5:0] data = 6'bO) { 

) 
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foodOO, 5, *); 
foo(*, 5, 6'bOOOlll); 

This example declares a task f oo with default arguments. The first call to f oo is equivalent to 
foodOO, 5, 6'bO). The second call to foo is equivalent to foo(0,5,€'b000lll). 



To allow subroutines to evolve over time without having to change all of the existing calls. Vera sup- 
ports optional arguments. Optional arguments are encapsulated by parentheses, and they must have de- 
fault values. The syntax is: 

sxxbroutine{ {optional^^rgl) , ( {optional_arg2) ) , ( ( ( op fciona i_arg5) ) } ) 
{statements} 

Any number of additional optional arguments can be created. The number of nested parentheses deter- 
mines the depth level of the optional argument For example: 

( (x=l) ) , ((y=l)) // Both arguments are level 2 
((x=l, y=l)) // Both argruments are level 2 
((x=l) , (<y=l))) // X is level 2, y is level 3 

When a subroutine with optional arguments is called, the parameters fill up the lowest level arguments 
first. When the lowest level is satisfied, higher levels are then filled in ascending order. Note that the 
order of the arguments does not depend on the nesting level. For example: 

task iny_task(a, ( (b=l) ) , (c=l)); 

This example declares a task with the required argument a, the level one argument c, and the level two 
argument h. These are examples of task calls using this declaration: 

my^taskO; // Illegal because the argument a has no default 
my_task(l) ; // Calls task with a=l 
iny_task(l, 2) ; // Calls task with a-1 and c=2 

Note that the arguments are filled according to their nesting level. However, if enough ai^gumcnls are 
passed to fill all of the optional arguments, the arguments are assigned values in order. For example: 

iny_task(l,2,3) ; // Calls task with a=l. b=2, and c=3 



External definitions allow you to use multiple source files. This lets you compile large functions sqia- 
rately, which facilitates debugging. 



4.6.6.4 Optional Arguments 



4.6.7 



External Definitions 
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ASJA Declaring External Subroutines 

You can create subroutines in multiple source files. If you use multiple source files, you must declare 
the subroutines as external at the top level The syntax to declare a subroutine as external is: 

extern subroutine {arguments) ; 

Alternatively, you can generate a header file when you compile the source code by using the -h switch 
(see Section 18.4, **Compile Options**). The generated header file contains all of the extern statements 
for that module. If you include this file, you do not need to manually declare the subroutines as extern. 



Note - When using external subroutines, the argument types that are passedi 
must match exacdy. So take extra care when passing arguments to external 
subroutines. 



4.6.7.2 External Default Arguments 

The default values can be set locally, and independentiy, for each compilation unit using extern decla- 
rations with default values. This allows writing a general library, which can then be customized for a 
particular user or testbench by using include files with different defaults. 

For example, the task f 00 may be defined in a separate library, which is compiled independenUy. The 
Vera file in which the task foo will be used must declare f 00 as being external, and in this extern dec- 
laration, you can set default values: 

// file A (library) 

task foo (integer i, k, bit 15:0] data) { 
// foo definition 

} 

// file B (testbench) 

extern task foo ( integer i = 10, integer k, bit [5:0] data=6'bllllll ); 

task xyz () { 

foo <*, 5, *); 
// 

} 
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Example 1 : Vera Basics 



This is an example of an arbiter. The example includes these features: 

• File inclusion and text macros 

• Interface specification 

• Ports and binds 

• Signal operation 

• Subroutines 

This example includes these files: 

• arbAf.vT 

• $igncdjirive,vT 

• RUN (a run script) 



tdefine OUTPUT.SKEW #1 
#define INPUT_EDGE PSAMPLE 

interface arb 
{ 

output [1:0 J bus_req PHOLD OUTPUT_SKEW; 

input [1:0] bus_gnt 1NPUT_EDGE vca rO; // vca monitor 

output [31:0] jnem_addr PHOLD OUTPUT_SKEW; 

incut [15:0] menudata INPUT_EDGE PRZ OUTPUT_SKEW vca rz; // vca monitor 
output oe PHOLD OUTPUT_SKEW; 
output ce PHOLD O0TPUT_SKEW; 

input ac3c XNPOT_EDGE vca rO; // vca monitor 
input elk CLOCK; 

} 

port generic_port 
{ 



br; 

bg; 

addr; 

data; 

oe; 



arb.if.vrh 
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ce; 



ack; 



} 



bind generic_port port_a 
{ 

br arb . bus_req 1 0 ] ; 
bg arb*bus_gnt[0] ; 
* addr arb.mein„addr; 
data arb . mem_data ; 
oe arb.oe; 
ce arb.oe; 
ack arb. ack; 



bind generic_port port_b 
{ 

br arb.bus_req[l] ; 
bg arb.bus_gnt [1] ; 
addr arb . menuaddr ; 
data arb.mem_data; 
oe arb , oe ; 
ce arb . ce ; 
ack arb. ack; 



# include <vera_de fines . vrh> 
#include 'arb.if.vxh" 

program signal_test 
{ 

bit [15:0] write_data_a[4] , write_data_b[4] , read_data_a [ 4 ] , 
read_data_b [ 4 ] ; 

// reset the request 

eO port_a.$br <= I'bO ; 
eo port_b.$br = I'bO ; 

// turn vca on for unexpected signal changes 
vca ( ON, arb ) ; 



// initiate burst write with both port_b and port_a at the same 



} 



} 



signaLdrive.vr 
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fork 
{ 

// port b 

integer i; 

for ( i = 0; i < 4; i++ ) 

write_data_bli3 = random (); 
do^write with port_b ( 32 'h0000„0008, write_data_b ); 

} 
{ 

// port a 

integer i; 

for ( i = 0; i < 4; i++ ) 
vnri t e_da ta_a [ i 1 = random ( ) ; 

do.write with port.a ( 32 'h0000_0004, write„data_a ); 

} 

join all 

// initiates burst read with both portjD and port_a at the same time 
// and verify the results 

fork 

{ //concurrent block 
// port„b 

integer i; 

do.read with port„b ( 32 'h0000_0008 . read_data_b ); 

for ( i = 0; i < 4; i++ ) 

{ 

if ( read_data_b[i] !== write_data„b[i3 ) 

error ( -port^b transactions gives inconsistent data!\nM; 
else 

print f Cport.b data %0d OK!\n*, i ); 

) 

} // end concurrent block 
{ //conc;irrent block 
// port_a 

integer i; 

do_read with port„a ( 32 'h0000_0008 , read_data_a ); 

for ( i = 0; i < 4; i++ ) 

{ 

if ( read_data_a[i] !== write_data_ali] ) 

error ( 'port^a transactions gives inconsistent data!\n"); 
else 

printf Cport.a data %0d OK!\n', i ); 

} 

} // end concurrent block 
Synopsys Inc. • i 



1 02 Example 1 : Vera Basics 



Vera 4.0 User's Manual 



join all 

printf (•\n All Finished \n"); 

)//end program 

// do_read : request bus Ctrl from arbiter and do burst read at the 
// addr 

task do_read with generic_port < bit [31:0] addr, var bit [15:0] data [4] ) 
{ 

ei $br = I'bl; // start requesting for bus 

@1, 12 $bg == I'bl; // bus should be grant within 12 cycles 

80 $br = I'bO; // stop the request immediately 

82 $bg == I'bO; // grant signal should be de-asserted 

80 $addr <= addr; // drive the addr, oe, ce bits 
$oe = I'bl; 

$ce = I'bl; 

82, 10 $ack == I'bl; // ack should have come within 8 cycle 
fork 

{ // concurrent block 

880, 3 $ack == I'bl; // ack should stay for 4 cycles 

80 $oe <= I'bO; // at the end, deassert oe and ce 

80 $ce = I'bO; 
} // end concurrent block 
{ / / concurrent block 

integer i ; 

for (i = 0; i < 4; i-t-*-) // latch the data for 4 consecutive cycles 
{ 

8 (po sedge CLOCK) ; 
data[i] = $data; 
}//end for 
) // end concurrent block 
join all 

81 $oe = void; // void drive to kill one more cycle 
}//end do^read 

// do_write : request bus Ctrl from arbiter and do burst vrrite at 
// the addr 

task do_write with generic_port ( bit [31:0] addr, bit [15:0] data [4] ) 
{ 

81 $br = I'bl; // start requesting for bus 

81, 12 $bg == I'bl; // bus should be grant within 12 cycles 
80 $br = I'bO; // stop the request immediately 

82 $bg == I'bO; // grant signal should be de-asserted 
80 $addr <= addr; // drive the addr, oe, ce bits 

$oe = I'bO; 
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$ce = I'bl; 

§2, 10 $ack == I'bl; // ack should have come within 8 cycles 

fork 

{ 

@@0, 3 $ack == I'bl; // ack should stay for 4 cycles 
eo $ce = I'bO; 

} 
{ 

integer i? 

for (i = 0; i < 4; drive the data for 4 consecutive cycles 

{ 

$data = data[i3 async; 
^(posedge CLOCK); 
}//end for 

> 

join all 

ei $oe = void; // void drive to kill one more cycle 
}//end do_write 



RUN 

#!/bin/csh -f 

rm -f core *.vro *-vshell >& /dev/null 
vera -crop -g signal_drive,vr 



Synopsyslnc. --- «- 



1 04 Example 1 : Vera Basics 



Vera 4.0 User's Manual 



a 

m 
o 
a 

01 

a 
I- 

m 
a 



Synopsys-lnc. 



Vera 4,0 User's Manual 



Chapters. Sequential Control 10f> 



5. 



Sequential Control 



This chapter discusses the Vera coastnicts used for sequential flow control. It includes these sections: 

• If-clse Statements 

• Case Statements 

• Randcasc Statements 

• Repeat Loops 

• For Loops 

• While Loops 

• Break and Continue 



Vera supports if-dse statements as the general form of selection statements. The syntax to declare an if- 
clsc statement is; 

if (condition) if ^statement el«e else_stateinent; ^ 
condition - The condition can be any valid Vera exprcsMon. 

statement - Either statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

If the condition evaluates to true, the if^statement is executed. If it is evaluated to false, the 
else_statement is executed. 

The dse statement can be omitted. If the else statement is omitted, the conditional is evaluated and the 
ifjstatement executes only if it evaluates lo true. Otherwise, the program continues execution with Jthc 
first line after the if statement 

Vera supports nested if-dsc statements. 

This is an example of an if-eise statement: 

if (operator==0) y=a+b; 
else if ( operate r 5== 1) y=a-b; 
else if (operator"2> y=a*b; 
else ys='bx; 

This example uses sevc^ if*dse statements. Note that the final else statement is associated with tlie if 
statement immediately preceding it - 

VCTa also supports ? operator to replace if-else statements. The syntax is: 



5.1 



If-else Statements 
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condition ? if_statement : else^statement; 

This construct behaves exactly as the if-else construct. The condition is evaluated. If it evaluates to true, 
the if^statement is executed. If it does not evaluate to true, the elsejstatement is executed. 



5.2 Case Statements 

Vera provides the case statement for multi-way branching. The syntax to declare a case statement is: 

case {primary^expression) { 

casel^expression : statement; 
casB2_exprBSsion : statement; 

caseN^exprGSsion : statement; 
default : statement; 

} 

expression - The expressions can be any valid Vera expression, 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

The primary_expression is evaluated. The value of the primary_expression is successively checked 
against each case^expression. When an exact match is found, the statement corresponding to the match- 
ing case is executed, and control is then passed to the first line of code after the case block. If other 
matches exist, they are not executed. If no match is found, the default statement is executed. 

All case expressions must be the same bit length. *X' and 'Z' values arc actual signal values and are not 
ignored. 

This is an example case block: 

case ( bus [3: 0] ) { 

4'bOOZZ: packet = NULL; ' 
4'bOOOl: packet = READ; 
4'bOOlO: packet = WRITE; 
4,b00XX: packet = UNKNOWN; 
default: 
{ 

printf( *Error: illegal packet %h detected\n', bus [3:0] ); 
packet_error { ) ; 

} 

} 

If you want to use *X' or as a "don't care", use tiie casex or casez statements. *X' values are ig- 
nored when using casex, and *T values arc ignored when using casez. 

Synops^Tnc. 
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5.3 Randcase Statements 

The randcase statement creates a block of statements, one of which is executed randomly. The synta:c 
to declare a randcase block is: 

randcase { 

weightl $ statement!; 
weights t statements; 

weightN t statementN; 

^ \ V, 

weight - The branch weight can be any valid Vera expression, including a constant The expression is 
evaluated every time a randcase is executed. 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

When the randcase statement is executed, a statement is randomly selected from the block, different 
weights can be used to change the probability that any given statement is selected. The probability that 
any single statement is selected is determined by weightltotaljkveight. 

Randcase statements can be nested. 

This is an example of a randcase block: 

randcase { 
10: i=l; 
20: i=2? 
50: i=3; 

> 

This example defines a randcase block with the specified weights. There is a ,125 probability that tiae 
first statement is executed^ a .25 probability that the second statement is executed^ and a ,625 probal)il- 
ity that the third statement is executed. 

5.4 Repeat Loops 

The repeat loop executes a statement a fixed number of times. The syntax to declare a repeat loop is: 

repeat ( express! on) statement; 

expression - The expression can be any valid Vera expression, including constants. 

statement - The statement can be any valid Vera statement or block of statements. If a code block h 
used, the entire block is executed. 
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Repeat statements can be used to repeat any statement a fixed number of times. The value of the expres- 
sion is evaluated before the repetitions start. Changing a variable within the expression does not change 
the number of loops to be executed. 

Repeat statements are often used to implement a wait or pause in the simulation. For example: 

repeat (10) © (posedge CIX)CK) ; 
This example pauses the simulation 10 clock cycles. 

5.5 For Loops 

Vera provides the for construct for creating loops. The syntax to declare a for loop is: 

for {initial; condition; increment) statement; 
inituxl - The initial is an assignment statement used to set the loop control variables. 
condition - The condition can be any valid Vera expression. 

increment - The increment defines how the loop control variable changes each time the loop is 
repeated. It can be any valid expression, 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

The for loop sets the initial value of the loop control variable. It evaluates the condition. If the condition 
is true, the loop executes a single time. When the loop finishes one iteration, the update expression is 
executed. Typically this expression changes the value of the loop control variable. Then the condition is 
checked again and the process continues. The loop continues as long as the condition evaluates to true. 
When it does not evaluate to true, the loop stops and control is passed to the first line of Vera code after 
the loop. 

You can specify multiple variables in the irdtial statement, separating them with commas. Multiple vari- 
ables can also be used in the condition expression. These variables (with their initialized values) are 
passed to the loop and can be used within the loop for loop control or in Vera expressions. 

Vera does not allow assignments within the conditional. The conditional c=l is invalid. Instead, you 
must use c==l. 

These are some examples of Vera for loops: 

f or (cotmt=0 ; count<3 ; count=couiit+l) 

value=value-»- ( (a [count] ) * (coimt+l ) ) ; 

for (co;int=0 , done=0 , i=0 ; i*comt<125 ? 
printf ( *Value i = %d\n',i); 

jSyno^yslnc. 
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5.6 While Loops 

Vera provides the while construct for creating loops. The syntax to declare a while loop is: 

whale {condition) statement; 
condition - The condition can be any valid Vera expression. 

statement - The statement can be any valid Vera statement or block of statements. If a code block is 
used, the entire block is executed. 

The loop iterates while the condition is true. When the condition is false, control passes to the first line 
of Vera code after the loop. The condition is checked at the top of each loop. 

Vera does not allow assignments within the conditional. The conditional c=l is invalid. Instead, you 
must use c==l. 

This is an example of a while loop: 

operator = 0; 
while (operator<5) { 

opera t6r=operator+l ; 

printf ( "Operator is %d*, operator); 

} 

This loop continues until operator equals 5. Each time through the loop, operator is increased by L The 
check is made at the top of each loop. After 5 passes through the loop, the loop ends, and control is 
passed to the first line of code after the loop. 

If the condition is a non-zero constant, the loop becomes infinite. Infinite loops can only be broken us* 
ing the break statement (see Section 5.7.1, "Break"), 

5.7 Break and Continue 

Vera provides the break and continue statements for flow control within loops. 

5.7.1 Break 

The break statement is used to force the immediate termination of a loop, bypassing the normal loop 
test The syntax to declare a break is: 

break; 

When the break statement is executed from inside a loop, the loop is immediately terminated and con* 
trol passes to the first line of Vera code after the loop. If the break statement is executed outside of a 
loop, a syntax error is generated. 

This is an example of the break statement* 
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while (test_flag) { 
if (done) break; 

} 

This example breaks if the condition is satisfied. Control returns to the first line after the loop. 

5.7.2 Continue 

The continue statement forces the next iteration of a loop to take place, skipping any code in between. 
The syntax to declare a continue statement is: 

contimie ; 

In a repeat loop, the continue statement passes control back to the top of the loop. If the loop is com- 
plete, control is then passed to the first line of code after the loop. 

In a for loop, the continue sutement causes the conditional test and increment portions of the loop to 
execute. 

In a while loop, the continue statement passes control to the conditional test 
This is an example of a continue statement: 

for {i=0;i<10;i++) { 

if (skip_loop) continue; 



} 
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6. Concurrent Control 

This chapter discusses how Vera handles concurrency, II explains how to model parallel, independent 
activities and details the Vera constructs used to control those concurrent threads. It includes these sec- 
tions: 

• Fork and Join 

• Events 

• Semaphores 

• Regions 

• Mailboxes 

• Timeout Limit 

• Backward Compatibility 

SA ForkandJoin 

Fork/join blocks provide the primary mechanism for creating concurrent processes. The syntax to do 
Clare a fork/join block is; 

fork 

{sta^tementl; } 
{statements;} 

{statement^; } 
j oin wai t_op t i on 

sUUemeatN - The statements can be any valid Vera statement 

wait^option - The wait^option specifies when the code after the fork^oin block executes. The 

wait^option must be all. any, or none. The all option is the default Code after the block executes 
after all of the concurrent processes have completed. When the any option is used, code after the 
block executes after any single concurrent process is completed. When the none option is used, 
code after the block executes immediately, without waiting for any of the processes to complete. 
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The flow for a fork/join block is shown in Figure 6-1. 



( fork ) ( fo^^^ ) 



(join [all] j 



^ join any ^ 



Figure 6-1 Fork/Join Flow Diagram 



( fork ) 



I 



1 



7^ — ^ 

{ joxn none ) 



Note - When defining a fork/join block, do not encapsulate the entire fork 
inside braces {{ }). Doing so results in the entire block being treated as a 
single process, and the code executes consecutively. For example, avoid this 
construct: 

fork { 

{statementl; } 
{statement2; ) 

} 

join 



This is an example of a basic fork^oin construct: 

fork 
{ 

61,100 foo„bus,ack == I'bO; 

printf ■(•First Block: foo_bxis,ack is drivenXn'); 
} 

{ 

eS foo_bus.req = I'bO; 
ei foo_bus.req <- I'bl; 

printf ("Second Block: foo_bus,req is drivenXn'); 
} 

join 
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The concurrent block executes all the statements in parallel. The beginning of each statement is execut- 
ed at the same point in time. Subsequent statements are executed based on any timing considerations 
within the process. 

6.1.1 Fork and Join Control 

Vera provides several constructs to control fork/join blocks. Vera uses the wait.chttdO, wait_varO, and 
terminate constructs to wait for the completion of processes and stop the execution of processes. Vera 
also includes the suspend.threadO system task to temporarily suspend threads, 

6-1.1.1 wait^childO 

The wait_childO system task is used to ensure that all child processes are executed before the Vera pro- 
gram terminates. The syntax is: 

wait.childO ; 

By default. Vera terminates a simulation when the end of the program is reached, regardless of the sta- 
tus of any child processes. Using the wait_childO task causes Vera to wait until all the child processes 
in the current context are completed before executing the next line of code. 

This is an example of a program using the wait„child() construct: 

program test 
{ 

start.monitorsO ; //Starts monitors that loop forever in background 
do_test(); //Performs the actual test 

} 

task start_monitors () 
{ 

fork 
{..,} 

join none 

} 

task do_test() 

{ ' . • 

//Code to do testing. 

fork 

{...} 

join ndne //Creates child processes that take an indeterminate amount 

//of time to cocqplete ^ ..- 

wait_child() ; 

} 

r 
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This example calls two separate tasks. The do^test task forks off several child processes thai lake an 
indeterminate amount of time to complete. The wait^childQ call waits for the threads called in the 
do_tes t task to complete before executing subsequent Vera code. Note that the wait_chiid() call docs 
not wait for any child processes created outside of its context 

6.1.1.2 wait_varO 

The wait_varO system task blocks the calling process until one of the variables in its arguments list 
changes values. The syntax is: 

wait„var ( variables) ; 

variables - The variables are one or more variables (separated by commas) of type integer, bit, string, 
array, or enumerated type. 

The wait_varO task blocks the current process until one of the specified variables changes value. Only 
true value changes unblock the process. Reassigning the same value does not unblock, Jf more than one 
variable is specified, a change to any of the variables unblocks the process. 

This is an example of the wait_varO task: 

bit [7: 03 data [100]; 
integer i ; 

fork 
{ 

wait_var (data [2 ] ) ; 

printf <*Data[2] has changed to: %d\n', data{2]); 

} 
{ 

for (i=0;i<100;i++) 
{ 

data ( i ] =raiidoin ( ) ; 
e (posedge CLOCK) ; 

} 

} 

join 

This example forks off concurrent processes. The first thread is suspended until the second element of 
array data is changed. The second process randomly changes the values within array data. When da- 
tall] is changed, the first process prints its message, 

6.1.1.3 terminate 

The terminate statement terminates all active descendants of the process in which it was called. The 
syntax is: 

~- 
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terminate ; 

If any of the child processes have other descendants, the terminate command terminates them as well. 
If used at the top level, terminate terminates all child processes. When the main program is complel^sd. 
Vera executes an implicit terminate statement. 

This is an example of how terminate is used within a simple fork/join block: 

task do_test() 
{ 

// Code to do testing 

fork 

{...} 

join any// Creates child processes that take an indeterminate amount of 

//time to complete 
// Code to do more testing 
terminate ; 

} 

This example forks off several child processes within a task. After any of the child processes is com- 
plete. Vera continues to execute code. Before the task is completed, all remaining child processes arj 
terminated. 

6,1.1.4 suspend_threadO 

The suspend.threadQ system task is used to temporarily suspend the cuiient thread. The syntax is: 
«u8pend_tbxead ( ) ; 

The suspend_tfareadO system task temporarily suspends the current thread and allows other ready con- 
current threads to run. When the other threads are done, the suspended thread resumes execution. For 
example: 

for (i=0;i<10;i++) 
{ 

fork ' '* ^ ' 

my_task(i) ; » 
join none 
suspend_thr ead ( ) ; 

} 

This example forks multiple threads calling ircy^task. The thread is forked,- the task is called, and then 
the thread is suspended. The next iteration of the loop occurs and forks the next thread. Tliat thread be- 
gins execution and is suspended. All 10 threads are created, begin execution, and arc suspended. Con- 
trol returns to the first thread, and then each is executed in sequence. Using this construct, you do not 
need to declare i as a shadow variable. 
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Note - Suspended threads execute after all other current threads execute. 
However, relative to simulation time, the thread is still executed concurrently 
with the other threads. 



6.1 .2 Shadow Variables 

By default, all child processes have access to the parent's variables. However, if multiple processes in- 
dependently vmte to the same variable, races can occur. To avoid races within fork^oin blocks. Vera 
uses shadow variables. The syntax to declare a shadow variable is: 

shadow data_type variahle^najnej 

Using the shadow keyword forces the Vera compiler to create a copy of the variable local to each child 
process, which eliminates race conditions. 

This is an example of how shadow variables are used: 

shadow bit [31:0] address; 
shadow bit [31:0] data; 
integer i ; 

for {i=0; i<nuin_try; i++) 
{ 

repeat ( random ( ) %MAX_DELAy ) @ ( CLOCK) ; 
address=random ( ) ; 
data=randoin() ; 

printf { "Random access with Addr:%h Data%h\n'' , address, data); 
fork 
{ 

Memory„Acc es s ( addres s , da ta ) ; 
} 

join none 
} 

This example declares the variables address and data as shadow variables. The for loop then randomiz- 
es these variables and forks off a child process that calls the function Memory_Access witii address 
and data as parameters. The loop continues witiiout waiting for the child process to complete because of 
the j oin none statement The shadow variables must be used in this instance to ensure that the call to 
Memory_Access is made with variables that have not been re-randomized by subsequent loops. 



6.2 Events 



Events are variables that synchronize concurrent processes. When a sync is called, a process blocks un- 
til another process sends a trigger to unblock it Events act as the go-between for triggws and syncs. 
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6,2.1 Triggers 

Triggers are used to send events. The syntax to call a trigger is: 

trigger ( [ tri gger^ type , ] even t_name) ; 
trigger Jype - Table 6-1 lists the trigger types with a brief definition. 
Table 6-1 Trigger T^pcs 



Trigger l^pe Action 



ONE.SHOT Triggers pending syncs (default) 

ONE_BLAST Like ONE.SHOT, but it includes all syncs in the current c^dc 

HAND_SHAKE Triggers the oldest pending sync, or queues lequcst 

ON Ttas on the event 

OFF Turns off the event 

ev€nt_nam€ - The eventjname is the name of the event being triggered. 
ONE„SHOT 

The ONE_SHOT trigger is the default trigger type. If you use a ONE_SHOT trigger, any process wait- 
ing for a trigger receives it If there is no process waiting for the txiggcv, the trigger is discarded. 



PROCESS 1 syncl > 


sync2 




PROCESS 2 




PROCESS 3 


Trigger 



Figure 6-2 ONE.SHOT Triggers 

There is a danger when using ONE.SHOT triggers. Figure 6-2 shows a trigger called in process 3, Tlie 
trigger unblocks syncl. However, because the trigger and sync2 execute simultaneously, whether or 
not process 2 is unblocked depends on the execution order. The sync must be called before the trigger 
is executed when using ONE_SHOT triggers. If the sync is called after the trigger is executed, the pro- 
cess will wait indefinitely. 
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ONE^BLAST 

ONE_BLAST triggers work just as ONE„SHOT triggers with the exception that they trigger any sync 
called within the current cycle, regardless of whether or not it was called before the trigger was execut- 
ed. If a ONE_BLAST trigger is used for the situation diagrammed in Figure 6-2, all the processes are 
unblocked regardless of execution order. 

HAND_SHAKE 

HAND_SHAKE triggers unblock only one sync, even if multiple syncs are waiting for triggers. If a 
sync has already been called and is waiting for a trigger, the HAND^SHAIQE trigger unblocks the sync. 
If no sync has been called when the trigger occurs, the HAND_SHAKE trigger is stored. When a sync 
is called, the sync is immediately unblocked and the trigger is removed, 

ON 

The ON trigger is used to turn on an event. An event cannot be used to synchronize concurrent process- 
es if it is not tunied on. 

OFF 

The OFF trigger is used to turn off an event. An event cannot be used to synchronize concurrent pro- 
cesses if it is turned off, 

6.2.2 Sync 

The syncO system task synchronizes statement execution to one or more triggers. The syntax to call the 
syncO task is: 

«ync ( sync_ type , even 1 1 , even 1 2 , even tN) ; 

syncjype - The possible sync types and their definitions arc listed in Table 6-2. 



Table 6-2 Sync Types 



Sync Type 


Definition 


ALL 


Waits until all events arc triggered 


ANY 


Waits until any event is triggered 


ORDER 


Waits undl all events are triggered in the 




spedfied order 


CHECK 


Checks if all events are ON 



everUN - The event is the event variable name on which the sync is activated, 
ALL 

The ALL sync type suspends the process imtil all of the specified events are triggered. For example: 
sync (ALL, event_a, event_b, event_c) ; 
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This example suspends the thread until each of the events are triggered. Once they are triggered, the 
statement immediately following the syncQ call is executed, 

ANY 

The ANY sync type suspends the process until any of the specified events is triggered. For example: 
sync (ANY, event^a, event^b, event_c) ; 

This example suspends the thread until any of the specified events is triggered. Once one of the events 
is triggered, the statement immediately following the syncQ call is executed. 

ORDER 

The ORDER sync type suspends the process until all of the specified events are triggered in the given 
order. For example: 

sync (ORDER, event_a, event_b, event_c) ; 

This example suspends the thread until all of the specified events are triggered. As soon as an event is 
received out of order, the process unblocks and a simulation error occurs. Also, only the first event can 
be in the ON state when the sync is called. If both event_a and event_b arc ON when the call is 
made, a simulation error occurs. 



Note - Events that are set to NULL are always treated as if they were 
received in the correct order. 



CHECK 

The CHECK sync type is called as a function. It docs not suspend the thread. It returns a 1 if the trig- 
ger is ON and a 0 if it is not This sync type can only be used with ON and OFF trigger types. This sync 
type can only be used with a single event per call. For example: 

if (sync (CHECK, event_a) ) . 

print f ( "The . event is ON . \n* ) ; 

This syncO call returns a 1 if the event is on, and then prints the message. If the event is OFF^ a 0 is irc- 
tumcd. 

6.2.3 Event Variables 

Event variables serve as the link between triggers and syncs. They are a unique data type with sevci-al 
important properties. 
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6.2.3.1 Bidirectional Event Variables 

Event variables are bidirectional variables when used as arguments in syncs and triggers. The same 
event variable can be used to pass and receive triggers. For example: 

- task foo {event trigger_a) 
{ 

printf ( • NnFOO syncing at cycle=%Od*' ,get_cycle() ) ; 

sync (ALL, trigger_a) ; // Blocked: proceed after receiving trigger 
printf (•\nFOO event trigger„a received at cycle=%Od" ,get_cycle() ) ; 
repeat (5) ©(posedge CLOCK); 

printf (• \nFOO triggering trigger.a at cycle=%Od", get_cycle() ); 
trigger (trigger_a) ; 

} 

program trigger_play 
{ 

event triggerl; 
breakpoint ; 

// top block code starts here 
fork 

foo (triggerl) ;// start foo and go on 
join none 

repeat (8) 6 (po sedge CLOCK); //too is blocked waiting for event trigger 
fork 

printf (" \nPROGRAM triggering triggerl ecycle=%Od'' , get_cycle ( ) ) ; 
printf (" \nPROGRAM This unblocks foo"); 
trigger (triggerl) ; // unblock the waiting foo 

{ 

repeat (7) ©(posedge CLOCK); 

printf ( " \nPROGRAM syncing ecycle=%Od\n\n" , get_cycle ( ) ) ; 
sync (ALL, triggerl) ;// wait for foo to iinblock me 

■ > . ... 

join 

wait_child() ; 

printf ( "Trigger play done ! " ) ; 

} 

This example declares the task foo, which is called in the main program. Then foo is called in a thread 
forked off from the main program. The program continues without waiting for the child process to com- 
plete. Because foo contains a sync within its definition, the child process blocks, waiting for a trigger. 
Then another fork is used to fork off a trigger, which tmblocks the suspended foo. A second process in 
that fork then calls a sync. This sync occurs as foo is unblocked. Foo then continues its execution, 
which includes the execution of the trigger that unblocks the final child process. 

Synopsys Inc. 



Vera 4.0 User's Manual 



Chapters. Concurrent Control 121 



6.2-3,2 Disabling Events 

If an event variable is assigned a null value, the event is ignored in subsequent syncQ calls that may be 
waiting for a trigger on the event variable. For example: 

event boo = null; 
sync (ALL, boo) ; 

The sync is immediately satisfied because of the null value assigned to boo. 



6.2.3.3 Merging Events 

When an event is assigned to another event, the two are merged, which causes triggers on either one to 
affect both. For example: 

event boo, foo, woo; 
boo = foo; 
trigger (boo) ; 

trigger (boo) ; // this will trigger foo, as well 

trigger (foo) ; // t:his will trigger boo, as well 
boo = woo; 
foo = boo ; 

trigger (boo) ; // this will trigger foo and woo, as well 

trigger (foo) ; // this will trigger boo and woo, as well 

trigger (woo) ; // this will trigger boo and foo, as well 

However, use caution when merging events. The assignment affects subsequent triggers and syncs. For 
example, if a process is blocked waiting for eventl when you assign another event to eventl, the 
sync will never unblock. For example: 

fork 

while (1) (sync (ALL, foo);} 



while (1) {sync (ALL, boo);} 



foo = boo; 

while (1) {trigger (foo);} 

} 

join 
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This example forks off three concurrent threads. Each starts at the same time in the simulation. So, at 
the same time that threads 1 and 2 arc blocked, thread 3 assigns the event boo to f oo. This means that 
thread 1 can never unblock, because the event f oo is now boo. To unblock both threads 1 and 2, the 
merger of f oo and boo must take place before the fork. 

6.3 Semaphores 

A semaphore is a primitive operation used for mutual exclusion and synchronization. 

The semaphore system functions are: 

alloc ( SEMAPHORE, semaphore^ldr semaphore_coimt I, Jtey_count] ) ; 
semaphore jret iwait_option, semaphore_i d , key^weigh t ) ; 
semaphore jut ( semaphore_id, kGy_weigh t ) ; 

6.3.1 Conceptual Overview 

Conceptually, semaphores can be viewed as a bucket When you allocate a semaphore, you create a vir- 
tual bucket. Inside the bucket arc a number of keys. No process can be executed without first having a 
key. So, if a specific process requires a key, only a finite number of occurrences of that process can be 
in progress simultaneously. All others must wait until a key is returned to the virtual bucket 

6.3.2 allocO 

To allocate a semaphore, you must use the allocO system function. The syntax is: 

alloc (SEMAPHORE, semaphore^id, semaphore_coxmt [, Jcey_count] ) ; 

semaphorejd - The semaphore Jd is the ID number of the particular semaphore being created. It must 
be an integer value. You should generally use 0, When you use 0, Vera automatically generates a 
sem^hore ID. 

semaphore _count - The semaphorejcount specifics how many semaphores you want to create. It must 
be an integer value. 

key^count - The keyjcount specifics the number of keys allocated to each semaphore. 

The allocQ function returns the base semaphore ED if the semaphores arc successfully created. Other- 
wise, it returns 0, 

The maximum number of semaphores that can be created is determined by a nmtim.e parameter. See 
Section 18.5, *'Running Vera with HDLs," 

6.3.3 semaphore^etQ 

To check that there are enough keys left in the semaphore, you must use the semaphore^etQ system 
function. The syntax is: 

Syn<ppsys1nc. 
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seniaphore_get {waat_option, semaphore_id, key^weight) ; 

waitjopdon - The wait option can cither be NO_WAIT or WAIT. The NO_WAIT option continues 
code execution if there are not enough keys available. The WAIT option suspends the process until 
there arc enough keys available, at which time execution continues. 

semaphore Jd - The semaphore Jd specifies which semaphore to get keys from. 

keyj^eighi - The key^weight specifies the number of keys being taken from the semaphore. 

When the semaphore^getQ function is called, it checks the specified semaphore for the number of re- 
quired keys. If there are enough keys available, a 1 is returned and execution continues. If there are not 
enough keys available, a 0 is returned and the process is suspended depending on the wait option. 

The semaphore waiting queue is FIFO based. By default, a process will wait at a semaphore without 
timing out Users can set a time limit with the timeoutO system task. See Section 6.5.5, **Mailbox Ex- 
ample." 

If multiple sem^hores are allocated, you can access the Nth semaphore using this method: 

semID=alloc (SEMAPHORE, 0, 4, 2) ; 

if (seinaphore_get (WAIT, seraID+2, 1)) 

printf(*The semaphore was successful,'); 

This example allocates four semaphores with IDs 0 to 3, each with two keys. Then it checks to see if 
there is a key in the third semaphore. If there is, a message is printed, 

6,3-4 semaphore„putO 

To put keys back into a semaphore, you must use the semaphore_putO system task. The syntax is: 

•cmaphore_put (seinaphore_id, key^weight) ; 

semaphore Jd - The semaphorejd specifies which semaphore to return the keys to. 

keyjweight - The keyjweight specifics the number of keys being returned to the semaphore. 

When the semaphore_putO system task is called, the specified nimiber of keys is returned to the sema- 
phore. If a process has been suspended to wait for a key, that process executes when enough keys have 
been returned. 

6.3.5 Semaphore Example 

This is an example of basic semaphore usage: 

class gen 
{ 

local reg[2:0] Mt_field_a; 

static integer gu = alloc (SEMAPHORE, 0, 1, .1); 
task ml() 
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printfC'The value of guard %0d, in gen\n' , gu) ; 



} 



task new { ) 



{ 



bit_field_a = rsLndomO; 



} 



} 



progreim test 
{ 

integer i , j ; 
gen gl, g2 , g3; 

printf (*This is prograin test beginning. \n* ) ; 
gl =new ; g2 =new ; g3 =new ; 

printf(*Tiie gnd in main %0d %0d %Od\n', gl.gu, g2.gu, g3.gu); 



^(posedge CLOCK); 
semaphore_.get (WAIT , gl . gu , 1) ; 

printf{*This is gl semaphore^get at cycle %Od\n*^ get_cycle ( ) ) ; 
repeat (2) © (posedge CLOCK); 
seinaphore_put (gl ,gu, 1); 



@{posedge CLOCK); 

semapho re_get ( WAIT , g2 . gu , 1 ) ; 

printf(*This is g2 s emaphore_get at cycle %Od\n', get_cycle()); 
repeat (2) ^(posedge CLOCK); 
semaphore_pu t ( g2 . gu , 1 ) ; 



printf(*This is g3 seinaphore_get at cycle %Od\n', get_cycle()); 
repeat (2) §<posedge CLOCK); 
semaphore_put (g3 . gu ^ 1 ) ; 



} 

join all 

} 

This example creates class gen inside which a single semz^hore is allocated with 1 key. Within the 
main program, ^7, and g3 are instantiated. These arc instances of the class gen. However, there is 
only one semaphore because of the static declaration in the senu^hore allocation. Hien the main pro- 
gram forks off three separate threads. Each thread tries to get a key from the semaphore. If it is imable^ 



fork 



} 



} 



{ 



©{posedge CLOCK); 
seiaaphore_ge t ( WAIT , g3 , gu , 1 ) ; 



— ^ 
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il waits until a key is available. Once it gets the key. it prints a message, advances the simulation clock, 
and returns the key to the semaphore. In this way, each thread is suspended until a semaphore key is 
available, which can be used to prevent conflicts between threads. 

6.4 Regions 

A region is a mutual exclusion mechanism that guarantees that the requested values are unique in the 
simulation. This feature is provided mostly for random type simulations that may depend on the unique- 
ness of specific values such as addresses or data-IDs, 

The region system functions arc: 

alloc (REGIOK, region^id, region^coxmt) ; 

rcgion„cnter ( wai t_option, region^id, valuGl , value2, . . . , valueN) ; 
regioa_exit {region_id, valuel , valued, . . • , vaiueW) ; 

6.4.1 Conceptual Overview 

Conceptually, regions can be viewed as a set of letters. First you allocate which letters are included in 
the set These letters are the only letters from which words can be made. If one person uses the letters 
to spell CAT, no one else can spell TIN because the T is already in use. Once the T is returned, TIN can 
be created. Effectively, this ensures that data sets are unique, and it eliminates concurrent crossover, 

6.4.2 allocO 

To allocate a region, you must use the allocQ system function. The syntax is: 

alloc (REGION, regxon_id, region_count) ; 

regionjd - The regionjd is the ID number of the particular region being created. It must 

be an integer value. You should generally use 0. When you use 0, Vera automatically generates a 
region ID. 

region jcount - The region jcount specifics how many regions you want to create. It must 
be an integer value. 

The aUocO function returns the base region ID if the regions are successfully created. Otherwise, it re- 
turns 0. 

The maximum number of regions that can be created is determined by a runtime parameter. See 
Section 18ii, "Running Vera with HDLs." 

6.4.3 region_enterO 

The region.enterO system function checks to see if a particular region is in use. The syntax is: 



region_ent:er(wait_option, region_^id, valuel, value2. 
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waiijoption - The wait option can cither be NO.WAIT or WAIT. The NO_WAIT option continues 
code execution if the specified region is in use. The WAIT option suspends the process until 
the specified region is no longer in use, 

region Jd - The region Jd specifies which region that is being entered. 

valueN - The values are integer or bit vectors up to 64 bits, without X's or Z's. These values specify 
the unique region values. 

The region_eiiterO system function checks the specified values against all region values for the speci- 
fied region. If another process has entered the region with one or more of the values, then those values 
are in use, and the current region cannot use them. If none of the values are in use elsewhere, the func- 
tion returns a 1, flags the values as in use, and passes control to the next line of code. If one or more of 
the values is in use elsewhere, the function suspends the current thread until the values become avail- 
able, depending on the wait option. 

The region waiting queue is FIFO based. By default, a process will wait at a region without timing out. 
Users can set a time limit with the timeoutO system task. See Section 6.5.5, "Mailbox Example," 

6.4.4 reglon_exitO 

The region_exitO system task removes the specified values from the in-use state. The syntax is: 

rogion_exit (reflrioi3_id, valuel, value2, , valueN); 

regionjd - The region_id specifies which region that is being exited. 

valueN - The values are integer or bit vectors up to 64 bits, without X*s or Z's. These values specify 
the unique region values. 

When the region_exit() system task is called, the specified values arc no longer in use and can be used 
in other regions. Any processes that are suspended waiting for region values execute when the region 
values are made available, 

6.4.5 Region Example 

» 

This is an example of region usage: 

task CPU (integer id, integer grant, integer regID) 
{ 

integer data, address; 
bit [31:0] randVar; 

repeat(256) { 

randVar =random { ) ; 
address=randVar [13:6]; 
data=randVar [29:22] ; 
regioA_enter(WAIT, regID, address); 
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@1 memsys .request [id] =1 'bl ; 
@2,20 mems ys, grant ==gr ant; 
writeOp (address , data) ; 
ei memsys.reguest [id3=l'bO; 
e2,20 memsys. grant = =2 'bOO; 
ei memsys. request [id] =l'bl; 
02,20 memsys . grant = =gr ant ; 
readOp (address , data) ; 
ei memsys .request [id] =l'bO; 
62,20 memsys. grant==2'b00; 
region_exit (regID, address) ; 
repeat(randVar[20:17])e(posedge memsys. elk); 

} 

} 

regID=alloc (REGION, 0 , 1) ; 
forlc 

CPU(0, 2'bOl, regID) ; 
CPUd, 2'blO, regID) ; 
join 

This example repeats a loop 256 times. Within the loop, first a random 32 bit value is generated and as- 
signed to randVar, Then a random address and random data are assigned to address and data. Next, the 
region_cnterO call checks to see if the address is in use. If it is in use. the process suspends until the 
value is freed. When the value is not in use, execution continues until the region is exited, 

6.5 Mailboxes 

A mailbox is a mechanism to exchange messages between processes. Data can be sent to a mailbox by 
one process and retrieved by another. 

The mailbox system functions arc: 

alloc (mxI<&OX, mailJbox^id, mailboj^count) ; z._ 
mailbox jttt {mailboK^id, data); 

nailbox^et ( wai t_option, xnailboK^id { , dest^var i , check_optioii\ ] ) ; 

6.5.1 Conceptual Overview 

Conceptually, mailboxes behave like real mailboxes. When a letter is delivered and put into the mail- 
box, you can retrieve the letter (and any data stored within). However, if the letter has not been deliv- 
ered when you check the mailbox, you must choose whether to wait for the letter or retrieve the letter 
on subsequent trips to the mailbox. Similarly, Vera's mailboxes allow you to transfer and retrieve data 
in a very controlled mannen 
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6.5.2 allocO 

To allocate a mailbox, you must use the allocQ system function. The syntax is: 
alloc {KAIIiBOX, mailbox^id, mallbox^count) ; 

maUboxJd - The mailbox Jd is the ID number of the particular mailbox being created. It must 

be an integer value. You should generally use 0. When you use 0, Vera automatically generates a 
mailbox ID. 

mailbox jcount - The mailboxjcount specifies how many mailboxes you want to create. It must 
be an integer value. 

The aliocQ function returns the base mailbox ID if the mailboxes are successfully created. Otherwise, it 
returns 0, 

The maximum number of mailboxes that can be created is determined by a runtime parameter. See 
Section 18,5, "Running Vera with HDLs." 

6.5.3 mailbox^putQ 

The mailbox_put0 system task sends data to the mailbox. The syntax is: 

ma.ilbox,j?ut (jnaili30x_id, data}; 
mailbox Jd - The mailbox Jd specifies which mailbox receives the data. 

data - The data can be any general expression that evaluates to a scalar. This includes all data types 
discussed in Section 3^, **Data Types and Variable Declaration.*' 

The mallbox_put0 system task stores data in a mailbox in a FIFO manner. 

Note - mailbox_jiutO can ONLY be used with inailbox_getO. Using 
maObox^putO with mailbox.receiveO results in a runtime error. 

6.5.4 mailbox_getO 

The mailbox_getO system function returns data stored in a mailbox. The syntax is: 

iBailbox^et( vait^option, mailbox^id [, dest^var [, check_optionl ]); 

waitjoption - The wait option can either be NO_WAIT or WAIT. The NO^WAIT option continues 
code execution if the mailbox is empty. The WAIT option suspends the process until a message 
is sent to the mailbox, 

mailbox Jd - The mailbox Jd specifies which mailbox data is being retrieved £rom. 

dest_var - The dest^var is the destination variable of the mailbox data. 
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checkjoption - The checkjoption is an optional argument that should be set to CHECK when used. It 
specifies whether type checking occurs between the mailbox data and the destination variable. 

The mailbox_get0 system function assigns any data stored in the mailbox to the destination variable 
and returns the number of entries in the mailbox, including the entry just received. If there is a type 
mismatch between the data sent to the mailbox and the destination variable, a runtime error occurs un- 
less the CHECK option is used. If the CHECK option is active, a -1 is returned, and the message is left 
in the mailbox and is dequeued on the next mailbox_get0 function call. If the mailbox is empty, the 
function waits for a message to be sent, depending on the wait option. If the wait option is NCWATI, 
the function returns a 0, 

If no destination variable is specified, the function returns the number of entries in the mailbox, but it 
docs not dequeue an item from the mailbox. 

For example, this can be used to continue generating mailbox entries .until a specified number are gen- 
erated: 

mboxID=alloc (MAILBOX, 0, 1); 
while (inailbox_count <11) 
{ 

inb_data=random() ; 
itiailbox_put (mboxID, inb_data) ; 
mailbox_coiint=iaailbox^et (NO_WAIT , mboxID ) ; 

} 

This example generates random numbers ^uid puts them in the mailbox. The loop continues while the 
number of entries is less than 11, 

The mailbox waiting queue is FIFO based. By default, a process will wait at a mailbox without timing 
ouL Users can set a time limit with the timeoutO system task. Sec Section 6,5.5, **Mailbox Example," 

6.5.5 Mailbox Example 

This is an example of basic mailbox usage: 

inboxID=al loc ( MAILBOX ,.0,1); 
fork 

{ repeat (256) 

{ randomVar=random() ; 

address ( ) =randVar [17:0]; 
©1 inemsys,request [0] =l,bl; 
€2,20 inemsys.grant==2'b01; 
dataO=randVar [7 : 0 ] ; 
writeOp (address 0, dataO) ; 
xnailbox_put (mboxID, {addressO, dataO}); 
ei memsys • request [0] =l'b0; 
€2^20 inemsys,grant==2'b00; 
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randoin_wait ( ) ; 

} 

) 

{ repeat (256) 

{ inb_var=inailbox„get(WAIT, mboxID, message, CHECK); 
addxessl=message [15 : 8] ; 
datal=:inessage [7:0] ; 
61 memsys, request [1 3 =l'bl; 
62,20 memsys. grant ==2 'blO ; 
readQp(addressl,datal) ; 
ei memsys. request [13 =l'bO; 
62,20 memsys.grant=:=2'b00; 
random„wait ( ) ; 

} 

} 

join 

This example allocates a mailbox before the fork. The first thread then randomly assigns values to 
addressO and dataO, The data is then passed through a mailbox to the second thread, which is waiting 
for the data. That data is read into message and used for the readOp call. 

6.6 Timeout Limit 

A process will wait forever in semaphore, region and mailbox if the waiting resources are not available. 
However, the system task timeoutQ can be used to set a time limit The syntax is: 

timeout (object. type, cycle_limit [ , object^icH ) ; 

object Jype - The objectjtype specifies the type of object for which the timeout is defined. It must be 
EVENT, SEMAPHORE, REGION, or MAILBOX, 

cycleJimU - The cycle Jimit specifies the maximum number of cycles any request will wait 

object Jd - The object Jd specifies an individual resource for which the timeout is set If it is not 
specified, the timeout exists for all objects of the type specified.- 

When the timeoutO system task is used, it sets the maximum number of cycles that an object will wait 
for a request Hie cycles are based on the SystemClock, If the cycle limit is set to 0 cycles, the tim- 
eout is disabled. You can specify a timeout for a specific event or for all events of a certain type. 

When a semjqjhore, region, or event times out, a verification occurs. 

These are examples of timeout statements: 

timeout (SEMAPHORE, 100) ; 
timeout (REGION, 50, r„ID) ; 
timeout (EVENT, 20); 
timeout (myevent , 300); 
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Note - Specific timeouts take precedence over global timeouts. 



6.7 Backward Compatibility 

Versions of Vera prior to Vera 4.0 used different commands for mailbox usage: mailbox.sendO and 
inailbox_receive0. 

6.7.1 mailbox_send() 

The mailbox.sendO system task sends data to the mailbox. The syntax is: 

mailbox^send (mailbox^id. data) ; 
mailbox Jd - The mailbox Jd specifies which mailbox receives the data. 
data - The data can be an integer or bit veaor of any size. 
The mailbox_sendO system task stores data in a mailbox in a FIFO manner. 

Note - mailbox_send0 can be used with either mailbox^receiveO or 
mailbox^etO- 



6.7.2 mailbox^receiveO 

The mailbox.recciveO system function returns data stored in a mailbox. The syntax is: 
mailbox.receivo {vait_opti on, mailhox_id) ; 

waUjoption - The wait option can either be NO.V^AIT or WAFT. The NO.WAIT option continues 
code execution if the mailbox is empty. The WAIT option suspends the process until a message 
is sent to the mailbox. 

mailbox Jd - The mailbox Jd specifies which mailbox data is being retrieved from. 

The maabox_receiveO system function returns the data stored in the mailbox if there is any. If the 
mailbox is empty, the function waits' for a message to be sent, depending on the wait option. If the wdt 
option is NO.WAIT, the function returns a 0 and sets the error flag (see Section 7.3.1, **Error Handling** 
for information on error flags). 

The mailbox waiting queue is FIFO based. By default, a process will wait at a mailbox without timing 
out Users can set a time limit with the timeoutQ system task. See Section 6.5.5. "Mailbox ExampU^" 
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Example 2: Flow Control 

This is an example of the arbiter in Example 1. The example includes these features: 

• Fork and join 

• Triggers 

• Semaphores 

• Regions 

• Mailboxes 

This example includes these files: 

• arh.if.VT 

• signal_drive.vr 

• KUN (a run script) 

arb.if.vrh 

#define OOTPUT_SKEW #1 
tdefine INPUT_EDGE PSAMPLE 

interface arb 
{ 

output [31:0] mem^addr PHOLD OUTPUT_SKEW; 

inout [15:0] menudata INPUT„EDGE PRZ OUTPUT_SKEW vca rz; // vca monitor 
output oe PHOLD OUTPUT_SKEW; 
output ce PHOLD OUTPUT_SKEW; 
ixgput ack INPtJT_EDGE vca rO; // vca monitor 
input elk CLOCK; 

} 

port generic_port 
{ 

addr; 
data; 
oe; 
ce; 
ack; 

} 

bind generic_j)ort port„a 
{ 

addr arb.menu.addr; 
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da t a arb . mem^cla t a ; 
oe arb . oe ; 
ce arb.ce; 
ack arb.ack; 

} 

bind generic_port port_b 
{ 

addr arb,mein_addr; 
data arb*mein_data; 
oe arb . oe ; 
ce arb.ce; 
ack arb.ack; 



signaLdrive.vr 

# inc iude <ver a_def ines . vrh> 
# include 'arb^if-vrh' 
#define RSEED 32 'hl234_5678 
tdefine MB„ID_A 0 
tdefine MB_ID_B 1 

// modified from ch4_ex to use semaphore as an arbiter 
// to directly access the memory 

// port_a and port_b are used to access write-read sequences 
// region_enter/region_exit is deployed to protect memory 
// address being used by a either port not to be corrupted 
/ / by the other 

// mailbox are use to pass address information from the write 
// process to read process 

// trigger and sync are used for illustrative to signal the 
// end of processes 

program signal_test 
{ 

integer sem_id; // global semaphore 
integer reg_id; // global region 
integer inbox_id[23; // global mailbox 
integer rauidseed = RSEED; 
event evt[4]; // global events 
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// reset the oe and ce 
@0 arb.ce <= I'bO ; 
@0 arb.oe = I'bO ; 

// turn vca on for unexpected signal changes 

vca { ON, arb ) ; 

// allocate 1 semaphore with initial value of 1 

sem„id = alloc ( SEMAPHORE, 0, 1, 1 ); 

if ( senuid == 0 ) error ("semaphore allocation failed!'); 

// allocate 1 region 

reg„id = alloc ( REGION, 0, 1 }; 

if ( reg_id == 0 ) error ("region allocation failed!"); 
/ / initiate burst write -read with both port„b and port_a at the same time 

fork 
{ 

// port b 

integer i; 

bit [31:0] addr; 

bit [15:0] dataE4]; 

repeat (10) 
{ 

addr = random ( rands eed) t 32 'h0000_f f f f ; 

region_enter ( WAIT, reg_id, addr ); // protect the addr 
for ( i = 0; i < 4; i++ ) 

data[i] = random ( rands eed ) ; // generate data 
do_write with port_b ( addr, data ) ; // do actual write 

// ^ass the addr and data to the read-process 

mailboK-Put ( inb03;„id[MB„ID„B3 # addr }; 
inailbox_put ( inbox_id[MB_ID_B3 , data[0] ); 
mailbox^put ( inbox„id[MB_ID_B] , data[l] ); 
mailbox_put ( robox_id[MB„ID_B] , data [2] ); 
mailbox_put ( inbox_id [MB_ID_B] , data [3] ); 
}//end repeat 

trigger ( ONE_BLAST, evt[0] ); // signal finish 

} 
{ 

// portjb 

integer i; 
bit [31:0] addr; 

bit [15:0] exp_data[4], data[4J; 
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repeat ( 10 ) 
{ 

inailbox_get ( WAIT, robox„id[MB_ID_B3 , addr ); //capture the addr 

do„read with port_b ( addr, data ); // do actual read 

// verify the data read 

for ( i = 0; i < 4; i++ ) 
{ 

// capture the expected data value 

inailbox_get ( WAIT, inbox_id[MB_ID_B3 , exp_data[i3 ); 
if ( data[i] »== exp_data[i] ) 

error ( "port^b transactions gives inconsistent data*\n*); 
else 

printf ("cycle %0d: portjb data %0d OK! \n', get^cycle () , i ); 

} 

region_exit { reg_id, addr ) ; //done with the addr 
}//end repeat 

trigger ( ONE_BLAST, evt[l] ); // signal finish 



// port a 

integer i ; 

bit [31:0 3 addr; 

bit [15:0] data[43; 

repeat (10) 
{ 

addr = random (rands eed) & 32 'hOOOO^f f f f ; 

region_enter ( WAIT, reg_id, addr ); // protect the addr 
for ( i = 0; i < 4; i++ ) 

data [i 3 = random ( rands eed ) ; // generate data 
do_write with port_a ( addr, data ) ; // do actual write 

// pass the addr and data to the read-process 

znailbox_put ( inbox„idEMB_ID_A3 , addr ) ; 

inailbox_put ( inbox_idCMB_ID„A3 , data[03 ); 

inailbox_put ( inbox_id (MB_ID_A3 , data [13 ); 

inailbox_put ( inbox_id[MB_ID_A3 , data [23 ); 

inailbox_put ( inbox_id[MB_ID_A3 , data (3 3 ); 
}//end repeat 

trigger ( ONE_BLAST, evt[23 ); //signal finish 

} 
{ 

// port_a 



} 



{ 
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integer i ; 

bit [31:0] addr; 

bit [15:0] exp_datat4], data [4] ; 

repeat < 10 ) 
{ 

niailbox_get (WAIT, inbox_id[MB_ID_A] , addr); // capttire the addi- 
do_read with port_a ( addr, data ); //do actual read 

// verify the data read 

for ( i = 0; i < 4; i++ ) 
{ 

// captiire the data 

mailbox^et { WAIT, mbox.id [MB„ID„A] , exp_data(i3 ); 
if ( datali] ! == exp_data[i] ) 

error ( *port_a transactions gives inconsistent data!\n"); 
else 

printf ( "cycle %0d: port_a data %0d OK! \n- ,get_cycle{) , i) ; 

> 

region_exit { reg_id, addr ); // release the addr 
}//end repeat 

trigger ( ONE_BLAST, evt[3] ); // signal finish 

} 

j o in none 

sync ( ALL, evt[03, evt[l], evtl23, evtIS] ); 

printf CVn All Finished \n*); 

}//end program 

// do_read : acquire semaphore and do burst read at the addr 
// release semaphore by the end 

task do.read with generic_port ( bit [31:0] addr, var bit [15:0] data [4] ) 
{ 

// acquiring lock on to driving /sampling signals 
semaphore_get ( WAIT, senuid, 1 ) ; 
ei $addr <= addr; // drive the addr, oe, ce bits 
$oe = I'bl; 
$ce = I'bl; 

€2, 10 $ack == I'bl; // ack should have come within 8 cycles 

fork 

{ 

e@0, 3 Sack == I'bl; // ack should stay for 4 cycles 
eO $oe <= I'bO; // at the end, deassert oe and ce 
@0 $ce = I'bO; 

} 
{ 
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integer i ; 

for (i = 0; i < 4; // latch the data for 4 consecutive cycles 

{ 

^(poseclge CLOCK) ; 
data[i] = $data; 
}//end for 

} 

join all 

61 $oe = void; // void drive to kill one more cycle 

// releasing lock 

semaphore_put ( sem__id, 1 ) ; 
}//end do„read 

// do„write : acquire semaphore and do burst write at the addr 
// release the semaphore by the end 

task do_write with generi export ( bit [31:0] addr, bit [15:0] data [4] ) 
{ 

// acquiring lock on to driving /ssunpling signals 
semaphore_get ( WAIT, sem^id, 1 ) ; 
QrO $addr <= addr; // drive the addr^ oe, ce bits 
$oe = I'bO; 
$ce = I'bl; 

02, 10 $ack == I'bl; // ack should have come within 8 cycles 

fork 

{ 

@@0, 3 $ack == I'bl; // ack should stay for 4 cycles 
§0 $ce = I'bO; 

) 
{ 

integer i ; 

for (i = 0; i < 4; i++) // drive the data for 4 consecutive cycles 
{ 

$data = data I i] async; 
e (posedge CLOCK) ; 
} / /end for 

} 

join all 

01 $oe = void; // void drive to kill one more cycle 

// releasing lock 

semaphore_put ( sem_id, 1 ) ; 
}//end do_write 
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RUN 



#!/bin/csh -f 

rm -f core *.vro *.vshell /dev/null 
vera -cn^ -g signal_drive, vr 



Synopsys Inc. 



140 Example2: Flow Control 



Vera 4.0 User's Manual 



O 

SI 

m 

Q 
Q 

m 

hi 

a 

m 
a 



\ 



Vera 4.0 User's Manual 



Chapter?. Predefined Vera Tasks 141 



7. Predefined Vera Tasks 

Vera provides many predefined system tasks that are immediately available in the Vera environment 
This chapter discusses many of the system tasks and details their use. This chapter includes these sec- 
tions: 

• Vera I/O 

• Random Number Generators 

• Simulation Errors 

• Simulation Control 

• Reading Plus Arguments 

7.1 Vera I/O 

The tasks in this section are Vera's input/output tasks. 



7.1.1 Output 
printfO 

Vera supports a C-stylc printfQ system task that sends information to stdout (verilog.log) during the 
course of a simulation. The syntax is: 

print f ( * £m t_s tr * , argl , arg2 , . , . , argN) ; 
fmt^str . This is a C-style format string. The format specifiers that can be used are: ; . . 





or %H 


: print in hexadecimal format 


%d 


or %D 


: print in decimal format 


%o 


or %0 


: print in ocjtal format 


%b 


or %B 


: print in binary format 


%c 


or 9bC 


: print in ASCII character format 


%s 


Qr%S 


: print as string 



argN - These are the arguments to be printed. 

For %h, %d, %o, %b, the values are sized automatically to the maximum possible space needed for the 
given expression. You can minimize the size by inserting a zero between the % character and the IcttCT 
that indicates the radix. For example: 
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printf (*Data - %0h Addr = %Oh\n", data, addr) ; 
With %s, you can also print bind_var variables. For example: 

bind_var current; 
current = get_bind ( ) ; 

printf (-Current bind = %s\n", current); 
This example prints the bind name associated with the bind_var current, 

7.1.2 File 10 

Vera provides predefined tasks to read and write external files, 
fopenQ 

The fopenO system function opens a specified file. The syntax is: 

fopea {^filenaine', ""type"); 
filename - filename specifies the file to be opened, 
type - The argument type is one of the following: 

r: open for reading 

w: truncate or create for writing 

a: append or create for writing 
The fopenO function opens the specified file and returns a 32-bit file descriptor or 0 if it fails, 

fcioseQ 

The fdoscO system task closes the specified file. The syntax is: 

fclo«c {file^descriptor); 
filejdescriptor - There are three predefmed file descriptors in verajiefines.vrh: 

stdin: terminal input 

stdout: terminal output 

stderr. terminal error output 

fprintfO 

The fprintfO system task writes the output to a specified file. The syntax is: 

fprintf {file_descriptor, fmt^str) : 
fint_ttr ' The format string is the same as the printfO system task. 
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freadbO 

The freadbO system function reads binary data from a specified file and returns it as a bit vector. The 
syntax is: 

froadb(file_descriptor) ; 

The freadbO function reads binary formatted data from a specified text file, line by line, and returns the 
data as a bit vector. Lines with only white spaces and comments are ignored. Each line of the file must 
be in this format: 

white^space* binary comment* 
white^space - The white_space can be any number of spaces. 
binary - The binary must be a combination of *Q\ *l\ *z\ *x\ *Z\ *X* and *J , 
comment • The comment must be a Vera comment starting with *Vr. 

When the end of the file is reached, the function sets the error fiag. For more information on the crrcir 
flag, see Section 73, **Simulation Errors." 

freadhO 

The f readhO system function reads hexadecimal data from a specified file and returns it as a bit vector. 
The syntax is: 

frea<51i(file„des crip tor) ; 

The freadhO function reads hex formatted dau from a specified text file, line by line, and returns the 
data as a bit vector. Lines with only white spaces and comments are ignored. Each line of the file must 
be in this format: 

whitG_spacG* hex comment* 

hex 'The hex must be a combination of *0', *a' to T, 'A' to 'F, 'x'. *z\ *X\ *Z* and *J .The 
comment must be a Vera comment starting with 

When the end of the file is reached, the function sets the error fiag. For more information on the em^r 
flag, see Section 7,3, "Simulation Errors.*' 

freadstrO 

The freadstrO system function returns a string from a specified file. The syntax is: 
fre«d«tr (file_descriptor, mode); 

mode - The mode can be VERBOSE, which prints a warning and returns a mull string when the end of 
the file is reached, SILENT, which returns a null string when the end of the file is reached, or 
RAWIN, which is the same as SILENT except that comments and blank lines are not filtered out 
If the mode is not spedfied, the default is VERBOSE. 
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The freadstrO function returns a string containing a line of text from a specified file. The returned 
string docs not contain line-feed characters. Comments and blank lines in the input file are ignored by 
the function, unless the RAWIN mode is used. 

When the end of the file is reached, the function sets the error flag. For more information on the error 
flag, see Section 7.3, **Simulation Errors," 

rewindO 

The rewindO system task moves the file access pointer to the beginning of the file. The syntax is: 
rewind (fiIe_descriptor) ; 

File I/O Example 

This is an example that incorporates many of the predefined I/O functions: 

# inc lude <vera_de fines . vrh> 

program f ile_.io„test 
{ 

// Read 10 lines of 16 -bit hex data from an input file 
// and write it to another file 

bit [15:03 in_data [ ] , out.data [ 3 ; 

s t r ing in_„dat a_s t r ; 

integer f di , f do , i ; 

fdi = fopen { •input.dat", 'r* ); 
if ( fdi == 0 ) 

error ( • Can ' t open input , dat 1 \n " ) ; 

// input method 1 - freadh 

for ( i = 0; i < 10; i+-t- ) 

in_data[i] = freadh ( fdi ); 
rewind ( ^di ) ; , , 

// input met:hod 2 - f reads tr 
// and output met:hod 1 - fprintf 

fdo = fopen ( " output . dat • , •w" ); 
if ( fdo == 0 ) 

error ("Can't open output.dat! \n' ) ; 

i = 0; 

in_data_Etr = f reads tr { fdi ) ; 
while ( in_data_str.len{) > 0 ) 
{ 

sscanf ( in_data_str, ■%h*, out_data[i3 ); 
if ( out_data[i] !== in^dataCi] ) 
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error ( " Something ' s wrong \n " ) ; 
else 

fprintf ( fdo, •Output Data : %h\n" , out_data[i] ); 
in„data_str = f reads tr ( fdi ) ; 



randomizing test data. The random number generator is based on the Unix random number generator, 
which uses a non-liner, additive feedback algorithm with a 256-byte state and a period of at least 

randomO 

random ( [seed] ) ; 

seed - The seed is an optional argument that determines which random number is generated. The seed 
can be any valid Vera expression, including variable expressions. The random number generator 
generates the same number every time the same seed is used. 

The random number generator is based on the Unix random number generator, which uses a non-linear 
additive feedback algorithm with a 256-byte state and a period of at least 2^^. For more information on 
the Unix random number generator, see the Unix man pages (from a Unix shell, type **man random"),. 

The random number generator is deterministic. Each time you restart your program, it cycles through 
the same random sequence. You can make this sequence indeterminate by seeding the randomQ func- 
tion with an extrinsic random variable, such as the time of day. 

To generate random numbers, first call the randomQ system functipn with a 32-bit seed value. Then 
call the randomQ function without a seed each time you need a new random number. For example: 

random{ 184984 ); // Initialize the generator 

addr = {randomO ,random{) } ; ' 
ph_nx2inber = random () » 5; 

urandomQ 

The urandomQ function generates an unsigned 32-bit random number based on the same algorithm 
used by the randomQ function. The syntax is: 

urandoni( [seed] ) ; 



} 
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rand48() 

The rand480 function generates a 32-bit non-negative random number based on the lrand48() algo- 
rithm. The syntax is: 

rand48 ( t^eedl } ; 

For more information on the lrand48() algorithm, see the Unix man page^ (from a Unix shell, type 
"man L:and48"). 

urand480 

The urand480 function generates an unsigned 32-bit random number based on the mrand48 algorithm. 
The syntax is: 

ur&nd48 ( I seed] ) ; 

For more information on the mrand480 algorithm, see the Unix man page^ (from a Unix shell, type 
"man mrand48"). 

7.3 Simulation Errors 

Vera provides a set of predefined tasks and functions that are used in handling simulation errors and in 
assisting the debugging process. 

7.3.1 Error Handling 

errorO 

The crrorO system task generates a Vera simulation error. The syntax is: 

error ( * fmt_str'' ) ; 
fint^str- The fmLstr is of the same form as the printfO function. 

You can intentionally generate a a simulation error condition with the crrorQ system task. The system 
task prints the message specified ynihfini_str and then generates the error. 

For example: 

if( length > 256 ) 

error ( *Too long lengtih %d specif ied\n* , length ); 

flagO 

The flagO system function sets and clears error flags. Tlie syntax is: 
flag ( [value] ) ; 

value - The value flag determines how the error flag is seL The value can be ON, which sets the error 
flag, or OFF, which clears the error flag. 
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The flagO function sets and clears error flags that are raised when various non-fatal simulation errors 
occur (such as soft-expects and semaphore timeouts). The function returns the value of the flag before 
setting or clearing the flag. If no argument is passed in the call, the function only returns the state of the 
error flag. 

If the error flag is set in a child process (in a fork/join block), the error flag is transferred to its parent 
only if the parent is waiting for the child. Returning from a task or procedure with the flag raised trig- 
gers a simulation error (default setup), and the flag is cleared. 

For example: 

foo_bus.data =?= 8'h54 soft; // soft expect 
if( flag 0 } { 

printf( ^Warning: data is not 8'h54\n* ); 
flag ( OFF ) ; 

} 

error^modeO 

The error_raodeO system task sets Vera's error generation mode. The sjmtax is: 
error^mode ( type , err or_ci ass ) ; 

type - The type must cither be ON, which activates the error generation mode, or OFF, which 
deactivates the error generation mode, 

error jclass - Tbe error jclass and its defaults arc lisiod in Table 7-1. 



Table 7-1 crror„class dcfimtion 



Error Class 


Definition 


Default 


EC.ARRAYX 


Eoor on indexing array with X value 


on 


EC_EXPECT 


Error on Expect fail 


on 


ECFULLEXPECT 


Error on FuII-Expcct fail ( **@ ) 


on 


EC.SEXPECT 


Error on Soft-Expect fail soft) , 


off 


EC_SFULLEXPECT 


Error on Soft-Full-Expect fail r@@" soft) 


off 


EC^RETURN 


Return from subroutines with error flag set, 
issues error message, and clears error flag 


on 


EC.USERSET 


flag(ON) system task is called by user 


off 


EC.SEMTMOUT 


sem^hore time out error 


on 


EC.RGNTMOUT 


region timeout error 


on 


EC_MBXTMOUT 


mailbox timeout error 


on 


EC_CX)NFLICT 


drive conflia error 


on 


EC^SOONFUCT 


Soft drive conflict enor 


off 
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For example: 

error_mode ( ON, EC_USERSET ); 
error_mode( OFF, EC_RETURN ); 

7.3.2 Debug Support Routines 

traceO 

The traceO system task enables and disables trace message generation for various types of objects. The 
syntax is: 

trace (request, object 1, idLlevel] ) ; 

request - The request must either be ON, which activates trace message generation, or OFF, which d 
activates trace message generation. 

object - The object argument definitions are listed in Table 7-2. 



Table 7-2 Trace object definitions 



Object 


Action 


SEMAPHORE 


trace message for semaphore 


REGION 


trace message for region 


MAILBOX 


trace message for mailbox 


PROGRAM 


trace message for program 


VERBOSE 


verbose message 


<evcnLvariable> 


trace all events on <event„variable> 



idjtevel - If the object argument is an event variable or VERBOSE, the idjtevel is not necessary. 

If the object argument is SEMAPHORE, REGION, or MAILBOX, the idjevel specifies the 
name of traced object 

If the object argument is PROGRAM, idjtevel specifies the trace level. Level 0 only traces the 
current process. Level I generates traces on child processes as well. For trace levels greater than 2, 
- the trace level is set to 1 for its subroutines. For example, with trace (ON, PROGRAM, 3), the trace 
level becomes 2 at the subroutine. 

Note - A new trace call overrides the given trace level. 

If the object argument is VERBOSE, the traceQ function controls the generation of the verbose 
messages, including the warning messages on soft-expect fail, etc. 
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When the program trace is enabled, the Vera-VS generates a trace dump along with the internal execu- 
tion. For example: 

<TRACE> Context{0): program rrarb_test 22 in rrarb,vr 
<TRACE> Context (0): program rrarb_test 23 in rrarb,vr 
<TRACE> Context (0): program rrarb„test 24 in rrarb.vr 

The trace shows the context ID (unique ID allocated by the system), program or subroutine name, line 
number, and file name. 

Program Trace Examples 

Here arc examples of program traces: 

trace ( ON, PROGRAM, 5 ); 

trace ( ON, SEMAPHORE, sem^id ); 

trace ( ON, REGION, addr_begin ); 

trace ( ON, MAILBOX, ups_inbox ); 

trace { ON, all_done_evt ); 

trace ( ON, VERBOSE ); 

trace ( OFF, PROGRAM, 1 ); 



7.4 Simulation Control 

Vera provides a set of of tasks and functions used to control simulations, 
stopO 

The stopO system task stops the simulation when it is encountered. The syntax is: 
•top ( ) ; 

The StopO system task is equivalent to the Verilog task $stop. If you are running a Vcrilog simulation, 
the simulation stops, reports that a stop has been encountered, and exits to a Verilog prompt when the 
task is encountered. Normal Verilog commands can be issued at the command line. To continue the sim 
ulation, enter a period (.) at the command line. 

If you are running Vcra-CS standalone, the simulation stops, reports that a stop has been cncountere<l, 
and prompts you to hit RETURN to continue. 



exitO 

The cxitO system task exits the simulation when it is encountered. The syntax is: 
' exit (status) ; 

status - The status must be an integer constant or integer variable. Its value is assigned to the 
environment variable $status when the simulation is exited. 
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The cxitO exits the simulation when it is encountered. It assigns the status value to the environment 
variable $status, which can be evaluated from the Unix prompt. It is particularly useful for evaluating 
flag and variable values when the simulation exits. 

get_cycleO 

The get_cycle system function returns the current simulation cycle count. The syntax is: 
ff«t_cyclo ( ) ; 

Vera counts the internal simulation cycles at the positive edge of SystemClock. The system function 
get.cycleO returns the current simulation cycle as a 32-bit unsigned value. 

For example: 

printf( ^Current Cycle: %d \n', get„cycle() ); 
get_t5meO 

The get„time system function returns the current 64-bit simulation time as two 32-bit values. The syn- 
tax is: 

ffet_tiine ( word) ; 

word ' The word must be either LO, which returns the lower 32-bit value, or HI, which returns the 
higher 32-bit value. ■ ^, 

The simulation time is evaluated from the HDL side, or from the Vera side when running Vera-CS stan- 
dalone. 

For example: 

printf( *Ciirrent Time: %d,%d \n', get.time (HI) , get.time (LO) ); 

get.systimeO 

The get_systimeO system fiinction returns the number of seconds since 00:00: UTC, January 1, 1970. 
The syntax is: 

get„«y«t:ime ( ) ; 

The get_systimcO system function corresponds to the Unix library function timeO (sec the Unix man 
pages for more information). 

7-5 Reading Plus Arguments 

Vera can read Verilog plus arguments using the get jlus_argO system function. The VHDL equivalent 
to plus arguments is included in the vercini file, discussed in Section 17.3.2, **VHDL Plus Arguments." 
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get_plus_arg() 

Within a Vera program you can check any plus arguments on the Verilog command line by using the 
get_plus_argO system task. 

get _pl^8_arg ( reques t , pi us^arg) ; 
request - The valid values for request are listed in Table 7-3. 



Table 7-3 Plus Aigumcat Requests 



Request 


Action 


CHECK 


returns 1 if the specified plus argument is 




present 


HNUM 


returns a hexadecimal number attached to the 




specified plus aigument 


NUM 


returns an integer attached to the specified 




plus argument 


STR 


returns a string attached to the specified plus 




argument (returns a bit string type and not a 




string primitive type) 



plusjarg - The plusjarg is the plus argument you want to evaluate. 

The get_plus_argO system function returns a value based on the request type and plusjarg value. 
For example: 

#include <vera_def ines , vrh> 
#define DEF_RP_TIMES 10 
tdefine DEF_RSEED 32 'habcd_ef 01 
tdefine DEF_U)G_FILE_NAME 'test* log- 
program test 
{ 

integer repeat^times = DEF_RP_TIMES; 
bit [31:0] random^seed = DEF_RSEED; 
bit [2047:0] bit_str; //max 256 char 
string log_f ile^name = DEF_IXX3_FII*E„NAME; 

// get repeat times if any 

if ( get_plus_arg ( CHECK, •set„repeat_times=" ) ) 
{ 

repeat_times = get_j>lus_arg ( NUM, *set_„repeat_timess=" ) ; 

} 

// get random seed if any 
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if ( get_plus_arg ( CHECK, •set_random_seed=" ) ) 
{ 

random_seed = getjlus_arg ( HNUM, "set_randoin_seed=" ); 

} 

// get log file name if any 

if ( get_plus_arg ( CHECK, ■ set_log_f ile_name=" ) ) 
{ 

bit_str = getjlus„arg ( STR, •set_log_f ile_name=" ); 
log_file„naine.bittostr { bit_str ); 

} 

printf (• repeat times is %Od\n" , repeat_times ); 
printf (• random seed is %h\n", random„seed ); 
printf (• log file name is %s\n", log_f ile„name ); 



This example is invoked with this command line: 

vera„cs filename. vro +set_repeat_times=7 +set_log„file_name= log, file \ 
+set_rajidom_seed=3 



} 
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8. Object-Oriented Programing 

Object-oriented programming is at the very core of Vera. The implementation is cleax^ straight- 
forward and elegant, assimilating and extending the best of the features found in C++ and Ja- 
va- For the new user, this implementation will prove easy to learn and powerful to use. The 
advanced user will find the Vera implementation to be intellectually deep and compelling. 

Most of the features of Vera are available without using the object-oriented framework You 
can be a good Vera programmer without ever defining a class, instantiating an object, or in- 
voking a method. The basic object-oriented capabilities, however, are straightforward and easy 
to learn, and tiie consequent improvements in your productivity will be immense. 

By using the object-oriented paradigm, yoxir program will be easier to design, easier to devel- 
op, easier to debug, easier to maintain, easier to share, and easier to re-use. This <ill follows 
from the fundamental orientation of the paradigm, which leads you to group related data and 
code into separable and separated units called classes. A class might be as low-level as a paclk- 
et or as high-level as a complete processor description. Each instance of a class, called an ob- 
ject, has its own copy of its data as well as access to the code that acts on this data. Classes 
have both public and private data and code. Private data and code inside the dass is inviolate 
- outside programs cannot access it, except indirectly through public access methods. Almost 
as importantly, code inside the dass can't have any imf oreseen side-effects outside of the dass. 
The focus of all code actions b strictly iitside the class. 

Object-oriented programming leads xiaturally to grouping related code and data together, 
keeping these sections small, easy to imderstcmd, easy to debug and easy to mmntain. It also 
leads to crisply formalizing the interactions among these dasses. The result is a disdpline and 
program structure that is useful for small programs, but has a dramatic, powerful impact on 
your productivity as soon as your program becomes large or in any way complex, ^ 

Object-oriented programming, espedally with a dean implementation sudi as is f oiind here, is 
more a matter of perspective and mindset than of features and syntax. The paradigm is buiJ!t 
on three tenets: encapsxilation, iiJieritanoe and polymorphism. 

Encapsulation is the concept of bringing related code and data together and making access 
into or out of the dass formal and rigorous, hiding almost all of the detail in the dass from tlie 
outside world. 

Inheritance is the idea that once a class is debugged, you don't want to modify it for a new £ip- 
plication or xise. You would rather inherit features you can use and replace features you neGd 
to change. This leads to the notion of a base dass with general, widely applicable core features 
and a class hierarchy of subdasses, where each member of ttie hierarchy inherits core features 
from its parent, adds new features that make the subda^ more specific and refined, and then 
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passes this more complete set on to its descendants. An example might be a base class that de- 
fines vehicles - providing the basic properties that are generic to all vehicles. We could then 
extend these properties to include the properties specific to land vehicles. This could be fur- 
ther extended to give us wheeled vehicles, then cars, then Toyotas and ultimately the Toyota 
Tercel - an actual example of a vehicle, a land-vehicle, a wheeled vehicle, etc Later, we could 
derive a new class for air-vehicles, motorcycles or Ferraris - all by extending the appropriate 
subclass. If we planned carefully we would not have to redo a lot of work, and the extensions 
would be straightforward. 

The third tenet of the object-oriented paradigm is polymorphism. This allows us to wait until 
run time to bind object variables to their data type. Traditional languages with simple data 
types don't allow you to do this; an integer is different frorh a string, and the two could never 
occupy the same variable. But with object-oriented programming, the range of data types are 
unlimited, and this traditional restriction often is a hindrance. For example, we might have a 
variable called coordinate where we have different versioi\s (classes) defining a coordinate: 
cartesian, polar, spherical, cylindrical, in two or three dimensions. The sulproutines would 
have the same names in all of the class declarations; all might have a subroutine that could 
compute the distance between two points or the distance from the origin to a point, dis- 
tance ( coordinate c ) , With polymorphism, when you call the subroutine distance ( ) at 
run time, the system looks at the type of the data (of coordinate) and decides which version 
of distance to invoke. 

8.1 Classes and Objects 

A class is a collection of data and a set of subroutines that operate on that data. A class's data 
is referred to as properties, subroutines are called methods, and we will refer to both as members 
of the class. The properties and methods, taken together, usually define the contents and capa- 
bilities of some kind of object. 

For example, a packet is an object It might have a command field, an address, a sequence 
number, a time stamp, and a packet payload. In addition, there are various things we can do 
with a packet initializing the packet, setting the command, reading the packet's status, check- 
ing the sequence number Each Packet is different, but as a class, packets have certain intrin- 
sic properties tiiat we can capture in a definition. 

Example: 

class Packet { 

bit [3:0] command; // data portion 

bit [40:0] address; 

bit [4:0] master_id; 

integer time^requested; 

local integer time^issued; 

local integer statiis; 

task new() { 
' . ' i , • command = IDLE; 



// initialization 
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address = 41 'bO; 
inaster_id - 5'bx; 

} 

/* private operations, internal to the class */ 
local task clean () { 

coinmand = 0; address = 0; master^id = 5'bx; 

} 

/* piiblic access entry points */ 
task issue_request( integer delay ) { 
// send request to bus 
// 

} 

fiinction integer current_status < ) { 
current_status ~ status; 

} 

} 

Note that a common convention is to capitalize the first letter of the class name, so that it is 
easy to recognize class declarations. 



8.2 Objects and Instance of Classes 

So far, we only have the definition of the class Packet. We have created a new, complex data 
type but we can't do anything widi the dass itself- We need to create an instance of the class, a 
single Packet object. The first step is to create a variable that can hold an object's name (or 
handle): 

Packet p; 

Nothing has been created yet We have just declared that p is a variable that can hold the ha:r\- 
dle of a Packet object In Vera, for p to refer to something, we need to expUdtly create an in- 
stance of the class using the new keyword. 

Packet p; 
p = new; 

You can detect uniiutialized object handles by comparing them with null. For example: 

class obj_foo 
{ 

} 

task mytask (integer a, (obj.foo myfoo = null)) 
{ 

if (myfoo == null) myfoo = new; 

} 

This example checks if myfoo is initialized. If it is not, it initializes it with the new command, 
Synopsys Inc, 
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8.3 Accessing Object Properties 

Now that we have created an object, we can use its data fields by qualifying property names 
with an instance name. Looking at the earlier example, we can use the commands for our 
Packet p as follows: 

Packet p = new; 

p. command = INIT; 

p , addres s = random ( ) ; 

time = p. time^reguested; 

8.4 Using Object Methods 

To access an object's methods, we use the same syntax we used to access properties: 

Packet p = new; 

status - p . current_status ( ) ; 

Note that we did not say 

status = current_status (p) ; 

The focus in object-oriented programming is the object, in this case the packet, not the func- 
tion call Also, objects are self-<ontained, with their own tnethods for manipulating their own 
properties. So we don't have to pass arguments to get_status { ) . The properties of a dass 
are freely and broadly available to the methods of the class, but each method only accesses the 
properties associated with its object, its instance. 

8.5 Constructors 

Vera does not require the complex memory allocation and de-allocation of C++. Construction 
of an object is straightforward and garbage collection, as in Java, is implicit and automatic. 
There can be no memory leaks or other subtle behavior that is so often the bane of C++ pro- 
grammers. 

Vera provides a mechanism for initializing an instance at the time the object is created. When 
you create an object, for example 

Packet p = new; 
the system executes the new task associated with the class: 

class Packet { 

integer command; 

task new () { command = IDIiE; } 
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Note that new is now being used in two very different contexts with very different semantics. 
The variable declaration creates an object of class Packet. In the course of creating this in- 
stance, the new subroutine is invoked, if it exists, allowing you to do any initialization or start- 
up functions you require. The new task is also called the constructor of a class. 

It is also possible to pass argiiments to the constructor, to allow for run-time customization of 
the object: 

Packet p - new(STARTUP, random get^time (LO) ) ; 
where the new initialization task in Packet might now look like 

task new (integer in_cornmand=IDLE, bit [40:0] in_address=0, 
integer tiine_stait^=0) { 
command = in_command; address = in_address; 
tiitie_reguested = timers tait?>; 

> ■ ? • 

The conventions for arguments are the same as for subroutine calls, including the use of dc^ 
fault argimients. 



8.6 Class Properties 

So far, we have only declared instance properties. Each instance of the class, each Packet, lias 
its own copy of each of its three variables. There are also cases where we only want one copy 
of the variable, to be shared by all instances. These class properties aie created using the stcit- 
ic keyword. Thus, for example, in a case where all instances of a class need access to a sema- 
phore id, we might have 

class Packet { 

static integer semid alloc (SEMAPHORE. 0, 1* 1); 

Now, semId will be created and irutialized the first time an object of the Packet class is cre- 
ated. Thereafter, every packet object can access the semaphore in the usual way: 

Packet p; ^ 
semaphore_get (WAIT, p.semid); 



8.7 this 

There are times when you need to xmambiguously refer to properties or methods in the ciu-- 
rent instance. For example, the following declaration is a common, dean way to write an iini- 
tialization routine; 
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class Demo { 
integer x; 

task new (integer x) { 
this.x - x; 
} 

X is now both a property of the class and an argument to the task new. In the task new, an un- 
qualified reference to x will be resolved by looking at the innermost scope, in this case the 
subroutine argument declaration. To access the instance property, we qualify it witti 'this' to 
refer to the current instance. 

Note that in writing methods, you can always qualify members wiflx this to refer to the cur- 
rent instance, but it is usually imnecessary 

8,8 Assignment, Re-naming and Copying 

When we declare a dass variable, we have oidy created a name for an object. Thus 
Packet pi; 

creates a variable, pi, that can hold the handle of an object of class Packet, but the initial value 
of pi is null It is not until we create an instance of type Packet that the object exists, and 
that pi contains an actual handle: 

pi = new; 
Thus, if we create another variable 

Packet p2; 
and assign pi to p2 

p2 = pi; 

then we still have only one object, which we can refer to with either the name pi or p2. Note, 
we have only executed new once, so we have only created one object 

If we rewrite the last expression sUghtiy differentiy, however, we make a copy of pi: 

p2 = new pi; 

Now we have executed new twice, so we have created two objects. VWth this syntax, however, 
p2 will be a copy of pi, but it will be what is known as a shallow copy All of the variables are 
copied across: integers, strings, instance handles, etc. Objects, however, are not copied, only 
their handles; as before, we have created two names for the same object This is true even if 
tiie class declaration includes the instantiation operator new: 
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// Create an object of class B 
// Create an object that is a copy of bl 
// i is changed in b2, but not in bl 
b2.ao = 50; // change object a, shared by both bl and b2 

test = bl.i; // test will be set to 1 (bl.i has not changed) 

test = bl,ao; // test will be set to 50 (a.j has changed) 

Note several things. We can initialize properties and instantiate objects directly in a dciss deo 
laration. Second, the shallow copy does not copy objects. Third, we can chain instance qualiii- 
cations as needed to reach into objects or to reach through objects: 

bl.a.j // reaches into a, which is a property of bl 

p * nex t - next, next .next, val // would chain through a sequence of 

// handles to get to val. 

To do a full (deep) copy, where everything (including nested objects) are copied^ you need to 
write custom code. Thus, we might have 

Packet pi = new; 
PacJcet p2 = new; 
p2. copy (pi) ; 

where copy (Packet p) is a method written to copy the object specified as its argument into 
its instance. 

8.9 Subclasses and Inheritance 

We have defined a class that declares a Packet. Now, assume we want to extend this declara- 
tion so that, for example, we could chain packets together on a list. We could create a new 
dass which has, as a property, a variable of type Packet. We would be nesting classes, like a 
set of Russian dolls; the references, as we saw in the previous example, can quickly become 
omibersome. 

A much preferred alternative is to extend the class, creating a new subclass that inherits the 
members of the parent class* Thus, for example, we could have 



class A {integer j = 
class B { 

integer i = 1; 

A a = new; 

} 

program test { 
integer test; 
B bl new; 
B b2 = new bl; 
b2.i = 10; 
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class LinkedPacket extends Packet { 
LinkedPacket next; 

function LinkedPacket get„next() { get_next = next; } 
} 

Now, all of the methods and properties of Packet are part of LinkedPacket - as if they were 
defined in LinkedPacket - and LinkedPacket has additional properties and methods, 

We can also override the parent's methods, changing their definitions. 

8.10 Overridden Members 

Subclasses objects are also legal representative objects of their parent classes. For example, ev- 
ery LinkedPacket object is a perfectly legal Packet object; we can assign the handle of a 
LinkedPacket object to a Packet variable: 

LinkedPacket = new; 
Packet p = Ip; 

In this case, references to p access the methods and properties of the Packet class. So, for ex- 
ample, if you have overridden properties and methods in LinkedPacket, when you refer- 
ence these overridden members through p you get the original members in the Packet class. 
From p, new and overridden members in LinkedPacket are hidden from you. 

class Packet { 

integer i = 1; 

function integer get() { get = i; } 
} 

class LinkedPacket extends Packet { 
integer i = 2 ; 

function integer get() { get = -i; } 
} 

LinkedPacket Ip = new; 

Packet p = Ip; ' . }: . ..u C;. tf ~l 

j = p.i; // j = 1. not 2 

j = p.getO; // j = 1, not -1 or -2 

Note that this is different from the semantics of, for example, Java. In Java, you would get the 
original properties, but you would get the overridden methods of the child class. In Vera, to 
get the overridden method, the parent method needs to be declared virtual (see below). 
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8.11 superclass 

Every subclass has a super class, its parent class referred to in the extends clause of the class 
declaration. When members have been overridden in the subclctss, you can access the super- 
clciss versions from methods in the subdass by qualifying the member name with the keyword 
super: 

super. count; 

super . clear_table ( ) ; 

This otdy allows you to reach up one level of the hierarchy; this may be a member declared a 
level up or a member inherited by the class one level up. There is no way to reach higher (su- 
per . super - count is not allowed). 

A - * * : 

(In the sequel, when we refer to subclasses, we will be referring to classes that are extensions 
of the current dass. When we refer to super-dasses, these will be the classes that the current 
dass is extended from^ beginning with the original base dass.) 



8.12 Casting 

It is always legal to assign subclass variable to a variable of superdass higher in the inherit - 
ance tree. It is never legal to directly assign a superdass variable to a variable of one of its suib- 
dasses. However, it may be legal to place the contents of the superdass handle in a subdass 
variable. 

• To check if the assignment will be legal, use the function cas t_assign ( ) : 

function integer cast_assign(var destination_handle, source_handle) ; 

This function diecks that the contents of source„handle is of class destination^handle or 
one of its subclasses. If it is, cast_assign does the assignment; if it is not, cast„assign [ ) 
generates an error and terminates, 

A second version of this function allows you to check the results without generating an error: 
cast_assign(destination_handle, source_handle , CHECK); 

does the assignment and retums.a 1 if flie assignment is valid. Otherwise, it sets the destina- 
tion handle to null and returns a 0. 



8.13 Chaining Constructors 

When you irtstantiate a subdass, one of the system's first actions is to invoke the dass method 
new ( ) . The first, implidt action new ( ) takes is to invoke the new ( ) method of its superdaiss, 
and so on up the inheritance hierarchy. Thus, all of the constructors get called, in the proper 
order, beginning with the base class and endir\g with the current class. 
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If the initialization method of the super-class requires arguments, you have two choices. If you 
want to always supply the same arguments, you can specify them at the time you extend the 
class: 

class EtherPacket extends Packet (5) { 

This will pass 5 to the new routine associated with Packet. A more general approach is to use 
the super keyword, to call the superclass constructor a$ the first executable statement of the con- 
structor: 

task new() { 

super. new (5) ; 

8.14 Data Hiding and Encapsulation 

So far, we have made all of oxir properties and methods available to the outside world without 
restriction. However, for most data (and most subroutines) we want to hide them away from 
the outside world, ''seal them away in the capsule" of the class. This keeps other programmers 
from relying on your specific implementation - so you can safely modify it later - and it also 
protects against accidental modifications to properties that are internal to the class. When all. 
data becomes hidden - being accessed only by public methods - testing and maintenance of 
the code becomes much easier. 

Unlabeled properties and methods are public, available to anyone who has access to the ob- 
ject's name, 

A member identified as local is available only to methods inside the class. Further, these lo- 
cal members are not visible even to subclasses and cannot be inherited. Of course, non-local 
methods that access local properties or methods can be inherited, and work properly as 
methods of the subclass. 

A protected property or method has all of the chzu-acteristics of a local member, except 
that it can be inherited; it is visible to subclasses. 

Note that within the dass, we can reference a local method or property of our class, even if 
it is in a different instance. For example 

class Packet { 

local integer i; 

function integer coir5>are (Packet other) { 
con^are = (this.i == other. i); 

} ^ * " 

A strict interpretation of encapsulation might say that other, i should not visible inside of 
this packet, since it is a local property being referenced from outside its instance. Within 
the same class, however, these references are allowed. In this case, this • i will be compared 
to other . i and ti\e result of the logical comparison will be returned. 
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In summary 

• wherever possible^ use local members. Hide members that the outside 
world doesn't need to know about; 

• use protected members if the outside world doesn't have a need to know^ 
but subclasses might; 

• public access should only be allowed when it is absolutely necessary, and the 
access should be limited as much as possible. Generally, don't provide direct 
access to properties but rather provide access methods - provide, for 
example, only read access if a variable should never be written. This 
provides an extra level of protection and preserves flexibiUty for future 
changes. 



8.15 Philosophy 

Notice that there has been a subtle yet profound shift in the way we are working with vari- 
ables. In a traditional programming language variables are either global, with too broad a 
scope, or local, with too lurrow a scope. Global variables often get woven through the fabric 
of the program, with no way, in large programs especially, to imderstand the ramifications of 
msJdng changes, or to keep programmers from relying on the implications and side effects of 
the specific implementation. Local variables have the opposite problem. They are so restricted 
in scope that you are always having to pass them explicitly, cluttering the code with redun- 
dant declarations and intermediate variables. 

In the object-oriented paradigm, we have created two intermediate classes of variables - much 
more visible than the old local variables yet much less visible than global variables. Variabkss 
which are declared local in the object-oriented paradigm are generally available, but only 
within a very carefully circim\scribed context - only to the methods of the variable's immedi- 
ate object. If your classes are well drawn, this is exactly the code that you want to have access 
to this type of variable. 

This scope can also be broadened a bit more, by declaring the variable static, hlow the vari- 
able becomes available to every object in the dass, but it is still not available to the majority of 
the code, the code that lies outside the clziss. ' 'T^'t&iv 

In object-oriented prograiruning, the language has become much more careful with the way 
variables are handled, while at the same time becoming more terse, more expressive'and eatsi- 
er to* read and understand. 

8.1 6 Abstract Classes and Virtual Methods 

Often we create a set of classes that can be viewed as all derived from a common base class. 
For example, we might start with a common base class of type BasePacket that sets out the 
structure of packets but is incomplete; we would never want to instantiate it From this baise 
class, though, we might derive a number of useful subclasses: Ethernet packets, token ring, 
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packets, GPSS packets, satellite packets. Each of these packets might look very similar, all 
needing the same set of methods, but they could vary significantly in terms of their internal 
details. 

We start by creating the base class that sets out the prototype for these subclasses. Since we 
don't need to instantiate the base class, we declare it to be abstract by declaring the class to be 
virtual: 

virtual class BasePacket { 

By themselves, abstract classes are not tremendously interesting, but abstract classes can also 
have virtml methods. Virtual methods provide prototypes for subroutines, all of the informa- 
tion generally foimd on the first line of a method declaration: the encapsulation criteria, the 
type and number of arguments, and the return type if it is needed. Later, when subclasses 
override virtual methods, they must follow the prototype exactly. Thus, all versions of the vir- 
tual method will look identical in all subclasses; 

virtual class BasePacket { 

virtual protected function integer send(bit [31: 0] data); 
} 

class EtherPacket extends BasePacket { 

protected function integer send (bit [31:0] data) { 
// body of the function 

} 

EtlierPacket is now a class we can instantiate. In general, if an abstract class has several vir- 
tual methods, all of the methods must be overridden for the subclass to be instantiable. If all 
of the methods are not overridden, the subclass needs to be abstract. 

Methods of normal classes can also be declared virtual. In this case, the method must have a 
, , body. If the method does have a body, then the class can be instantiated, as can its subclasses. 
However, if the subclass overrides the virtual method, then the new method must iexactly 
match the superclass's prototype, 

8.17 Finding the Right Method 

There are several subtleties that arise when we start using virtual methods, although the un- 
derlying rules are quite simple. At some point, the compiler or the nm-time system needs to 
find the proper method. If we have a simple ccise, with no inheritance, then the answer is ob- 
vious. 

. GigaEt:her Packet p = new; 
.p.sendO; 
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We will invoke the send ( ) method declared in GigaEtherPacket. But if we have inherited 
a virtual method, we need to find the right version. If GigaEtherPacket is a subclass, and 
doesn't declare send ( ) , where do we go? 

The first step is to decide where in the class hierarchy to begin searching for the method. The 
rule is simple: we begin searching from the class associated with the iiandle for the method we 
need to find: 

• in the case above, this would be the class GigaEtherPacket. 

• if the method is being invoked from inside another method, then the handle 
is the invoking method's class; if send ( ) now invokes setup ( ) , we would 
start with the class containing send ( ) : 

task sendO { 
setup ( ) ; 

the handle for this reference to setupQ is. of course, the implicit handle "this": 

task sendO { 
this . setup ( ) ; 

The second step is to search the hierarchy: 

« if the method is not defined at this level, begin going up the inheritance tree, 
tmless 

• the method is defined in the superclass as local, then the inheritance 
chain is broken (you can't inherit this method) and we have an error, or 

• we are at the base dass, in which case the method was not found 

• if the method is defined but is not virtual, use it. 

• otherwise, it must be virtual. Search from this dass down the inheritance 
tree. 

• if you find a non-virtual method, use it 

• if you hit the bottom of the tree, use the most recent virtual method with 
a body; this will be the method closest to the bottom of flie tree. If thfere 
is none, the search failed. 

This search criteria is straightforward. Go up the inheritance tree imtil you find a method you 
can use. If it is virtual, go back down the tree imtil you find a non-virtual metho<L If you hit 
bottom without finding one, then use ttie last virtual me&od with a body you came aaoss. 

For example, if we have 

class BasePacket { 

virtual task send (integer value) ; 

task initO { send(O); ) // calls a virtxial task • 

) 

class EtherPacket extends BasePacket { 
{ 

// no re-declaration of sendO or initO 
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} 

class Ether 100 extends EtherPacket { 
{ 

task send(integer value) { — } 
} 

EtherlOO ep = new; 

Now, if we invoke ep * init ( ) / the system will execute the version of ini t ( ) defined in 
BasePacket, but the version of send ( ) declared in EtherlOO . 

Note: If a method is declared virtual in a base clciss, it is usually a good idea to declare it vir- 
tual in ihe subclasses, too. 

8.18 Polymorphism: Dynamic Method Lookup 

Polymorphism allows us to use superclass variables to hold subclass objects, and to reference 
the methods of those subclasses directly from the superclass variable- As an example, consider 
the base class for our packet objects, BasePacket, Assume that it defines, as virtual func- 
tions, all of the public methods that are to be generally used by its subclasses, methods such as 
send, receive, print, etc Even though BasePacket is abstract, we can still use it to de- 
clare a variable: 

BasePacket packets [100] ; 

We can now create instances of various packet objects, and we can put these into the array we 
just created: 

EtherPacket ep = new; 
TokenPacket tp = new; 
GPSSPacket gp = new; 

packets [0] = ep; packets [1] = tp; packets [2] = gp; 

If our data types were, for example, integers, bits and strings, we couldn't store all of these 
types into a single array, but with polymorphism we can with objects. In this example, since the 
methods were declared as virtual, we can access the appropriate subclass methods from the 
superclass variable even though the compiler didn't know - at compile time - what was going 
to be loaded into, for example, packets [1] . 

packets [1] ,send() ; 

will invoke the send method associated with the TokenPacket class. At run-time, the system 
correctly binds the method from the appropriate class. 

This is a typical example of polymorphism at work, providing capabilities that are far more 
powerful than what is found in a non-object-oriented language. 
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8.19 Out of Block Declarations 

It is generally good coding practice to keep the class declaration to about a page. This makes 
the class easy to understand and to remember; declarations that go on for pages are hard to 
follow, and it is easy to miss short methods buried among the multi-page declarations. 

To make this practical, it is best to move long method definitions out of the body of the dass 
declaration* You do this in two steps. Wthin the dass body, you dedare the method prototype; 
- whether it is a function or task, any attributes (local, protected, public, and/or virtual), and 
the full spedfication of its arguments. Then, outside of the dass, you dedare the full method - 
including the prototype but without the attributes - and, to tie the metiiod back to its dass, 
you qualify the method name with the class ruune and a pair of colons: 

class Packet 
{ 

Packet next; 

function Packet get_next() { get^next = next; }// single line 
protected virtual function integer send (integer value); 

} 



function integer Packet :: send (integer value) 
{ // dropped protected virtual, added Packet:: 
// body of method 

} 

The first lines of each part of the method dedaration are nearly identical, except for the at- 
tributes and class-reference fields. 



8.20 External Classes 

As with subroutines, the dass dedaration can be in a separate file from tiie code that instanti- 
ates and invokes the dass; you need to provide an external declaration of the dass to support 
the tight type-checking required by Vera. The attributes and the method prototypes need to ]oe 
re-declared: 

extern class packet { 

bit [3:0] command; 

bit [40:01 address; 

bit [4:0] iaaster_id; 

task issu€_reguest ( integer delay ) ; 

function integer current_status () ; 

} 

Only the local and piiblic members of the dass must be listed in tiie extern dass declaration. 
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Note - The -h flag will cause the Vera compUer to automatically 
generate the extern class declarations for you, in a .vrh file. 



8.21 Typedef 

Sometimes you need to declare a class variable before the class itself has been declared. For ex- 
ample, two classes may each need a handle to the other. When, in Ae course of processing the 
declaration for the first class, the compiler encoimters the reference to the second dass, that 
reference is undefined and the compiler flags it as an erron The way aroimd this is to use 
typedef to provide an interim declaration for the second dass: 

typedef class C2; // C2 is declared to be of type class 

class CI { 

C2 c; 

} 

class C2 { 
CI c; 
} 

So, 02 is of type class, a fact that is re-enforced later in the source code. 
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Examples: Object-Oriented Programming 

This is an example of the arbiter in Example 2 xising the object-oriented methodology. The ex- 
ample includes these features: 

• Qasses and objects 

• Class properties 

• Subclasses and Inheritance 

• External classes 

This example includes these files: 

• arh.if.vr 

• main,VT 

• class€$.m 

• drivejtasks,vr 

• RUN (a nm script) 

The RUN script generates header files for classes.vr and drivejasks.vr, 

arb.if-vrh 

fdefine OOTPUT.SKEW #1 
#define INPUT_EDGE PSAMPLE 

interface arb 
{ 

output [31:0] meitL_addr PHOLD OUTPOT_SKEW; 

inout [15:0] ineicu<iata INPUT_EDGE PR2 OUTPOT_SKEW vca rz;// vca monitor 

output oe PHOLD 0UTPDT_SKEW; 

output ce PHOLD OtJTPUT_SKEW; 

input ack INPUT_EDGE vca rO; // vca monitor 

input elk CLOCK; 

} 

port generic_port 
{ 

addr; 
data; 
oe; 
ce; 
ack; 

} 
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bind generic^ort port_a 
{ 

addr arb . meituaddr ; 
data arb . mein_data ; 
oe arb , oe ; 
ce arb.ce; 
ack arb.ack; 

) 

bind generic^ort port_b 
{ 

addr arb.meiTL.addr ; 
data arb.mein_data; 
oe arb.oe; 
ce arb , ce ; 
ack arb.ack; 



main.vr 

# include <vera_de fines . vrh> 
# include *arb,if.vrh" 
# inc lude ■ clas ses . vrh * 

progreim classes_test 
{ 

integer sein_id; 
B_RD_Packet„Type rd_pack [ ] ; 
B_WR_Packet_Type wr_pack[]; 

// allocate one semaphore for exclusive access to memory 

sem_id = alloc ( SEMAPHORE, 0, 1, 1 ); 

fork 

{ 

// port_a stuff 
integer i ; 

// generate 10 wr-packets to write to 10 locations 

for ( i = 0; i < 10; i++ ) 
{ 

wr_pack[i] = new; 

do„whatever with port_a ( wr_packti] ); 

} 

// generate 10 rd-packets to read from 10 locations 

Syrlopsyslnc> 
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for ( i = 0; i < 10; ) 
{ 

rd_pack[i3 = new; 

rd_pack(i] .addr = wr_pack[i] .addr; 
do„whatever wit±i port_a { rd_^ack[i3 }; 

} 

} 
{ 

// portjD stuff 
integer i; 

// generate 10 wr-packets to write to 10 locations 

for ( i = 10; i < 20; i-«-+ ) 
{ 

wrjjackti] = new; 

do_whatever with port_b ( wr_pack[i] ); 

} 

// generate 10 rd-packets to read from 10 locations 

for { i = 10; i < 20; i++ ) 
{ 

rd_pack[i3 = new; 

rdjtackEi] -addr = wr_pack[i] ,addr; 
do„whatever with port J) ( rd_pack[i3 ); 

} 

} 

join all 

printf CNnXn All Finished \n-); 

}//end program 

task do^whatever with generic_port ( Action_Packet_Type apt ) 
{ 

// these virtual methods call mechanism will propagate down 
// and find the right version for the derived obj 

apt. action with < get_bind() ) (); 
apt . print_members ( ) ; 
}//end task do„whatever 



classes.vr 

# inc lude <vera_de f ines . vrh> 

t include "arb.if.vrh" 

i include " drive_tasks . vrh " 
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extern integer rands eed; 

// Virtual base class with 2 virtual function 

// for inherited classes to customize on their own. 

virtual class Action_Packet_Type 
{ 

virtual task print_ineinbers ( } ; 

virtual task action with generi export ( ) ; 

} 

// Derived class for action type of burst -read 

class B„Rr)_Packet_Type extends Action„Packet_Type 
{ 

static integer inst_nuiQ = 0; 
integer inst_id; 
bit [15:03 data [43; 
bit [31:0] addr; 

task new < ) 
{ 

addr = random ( randseed ) & 8'hfc; // 4-bytes aligned 
ins t_i d = ins t_num+ + ; 

printf (•B_RD_Packet_Type inst %0d is createdVn*, inst_id ); 

} 

task print^members ( ) 
{ 

integer i; 

printf CB.RD.Packet^Type inst %0d has the following members : \n' , 

inst„id ) ; 
printf addr : %h\n* , addr ); 

for <i = 0;i<4; i++ ) 

printf (• data[%Od] : %h\n-, i, data [i 3 ); 

printf CXnXn"); . • 

} 

task action with generic_port () 
{ 

printf CB^RD^Packet^Type iixst %0d will do a burst readXn" , inst_id) ; 
do_read with (get„bind()) ( addr, data ); 

} 

}//end B_RD_Packet_Type defn 
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class B_WR_Packet_Type extends Action_Packet_Type 
{ 

static integer inst_nuin = 0; 
integer inst„id; 
bit [15:03 data [4]; 
bit [31:0] addr; 

task new (} 
{ 

integer i; 

addr = random ( randseed ) t 8'hfc; // 4-bytes aligned 
for ( i = 0; i < 4; i++ ) 

datati] = random ( randseed ); 
inst„id = inst_num++; 

printf ("B.RD^Packet.Type inst %0d is createdXn", inst_id ); 

} 

task print_meinbers () 
{ 

integer i; 

printf (•B_RD_Packet„Type inst %0d has the following members : Xn" , 

inst_id ) ; 
printf (" addr : %h\n* , addr ); 

for ( i = 0; i < 4; i++ ) 

printf (• data[%Od] : %h\n", i, data[i] ); 

printf CXnXn-); 

} 

task action with generic_port () 
{ 

printf CB.WIUPacketjrype inst %0d will do a burst writeXn^, 
inst_id) ; 

do_write with (getJbindO) ( addr, data ); 

} ^' ' ' • 

)//end class B.WR^PacketJType defn 

drive^tasks.vr 

# inc lude <yera_de f ines . vrh> 
# include "arb-if-vrh" 

extern integer sertuid; 

// do_read : acquire semaphore and do burst read at the addr 
// release semaphore by the end 

..... ' — 
Synopsys inb. . ^. ' 
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task do_reacl with generic_port ( bit (31:0] addr, var bit (15:0] data[4] ) 
{ 

// acquiring lock on to driving/ sampling signals 

semaphore^get ( WAIT, sem^id, 1 ) ; 

@1 $addr <= addr; // drive the addr, oe, ce bits 

$oe = I'bl; 

$ce = I'bl; 

02, 10 $ack == I'bl; // ack should have come within 8 cycles 

fork 

{ 

e§0. 3 $ack == I'bl; // ack should stay for 4 cycles 
eo $oe <= I'bO; // at tl^e end, deassert oe and ce 
©0 $ce = I'bO; 



integer i ; 

for (i = 0; i < 4; i++) // latch the data for 4 consecutive cycles 
{ 

©(posedge CLOCK); 
data[i] = $data; 
}//end for 



join all 

ei $oe = void; // void drive to kill one more cycle 

// releasing lock 

seinaphore_put ( sem_id, 1 ) ; 
}//end do_read 

// do_write : acquire semaphore and do burst write at the addr 
// release the semaphore by the end 

task do_write with generic_port ( bit [31:0] addr, bit [15:0] data (4] ) 



// acquiring lock on to driving/san^sling signals 
semaphore_get ( WAIT, sein_id, 1 ) ; 
eo $addr <= addr; // drive the addr, oe, ce bits 
$oe = I'bO; 
$ce = I'bl; 

@2, 10 $ack == I'bl; // ack should have come within 8 cycles 

fork 

{ 

©&0, 3 $ack == I'bl; // ack should stay for 4 cycles 
eo $ce = I'bO; 

} 



} 



} 
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{ 

integer i ; 

for (i = 0; i < 4; 1++). // drive the data for 4 consecutive cycles 
{ 

$data = data(i] async; 
©(posedge CLOCK); 
}//end for 

} 

join all 

01 $oe = void; // void drive to kill one more cycle 
// releasing lock 

semaphore jut ( sem_id, 1 ) ; 
}//end do„write 



RUN 

#!/bin/csh -f 

rm -f core *.vshell *,vro >! /dev/null 

vera -cup -g -h drive_tasks • vr 

if {$status) exit 1 

vera -crap -g -h classes. vr 

if ($status) exit 1 

vera -arp -g main.vr 

if ($status) exit 1 
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9. Automated Stimulus Generation 

This chapter details Vera's automated stimulus generation. It focuses on constraint*driven stimulus gen- 
eration and data packing. This chapter contains these sections: 
« Introduction to Stimulus Generation 

• Stimulus Generation Overview 

• Random Packet Generation 

• Data Packing and Unpacking 



9.1 Introduction to Stimulus Generation 

Efforts to manually generate tests sufficient for verifying modem circuit designs have been rendered al- 
most completely ineffective. The sheer complexity of designs, involving hundreds of valid states and 
transitions, makes deterministic tests inconceivable. The burden of generating stimuli to drive simula- 
tions must fall squarely on the verification tool. 

Tlie solution resides not in data sets that drive simulation testbenches but in random stimuli that ensun? 
complete coverage of the hardware design. However, even this answer is not sufficient to efficiently 
and completely test a design. Tlie ability to narrow the scope of the random stimuli such that test cases 
are not repeated and unnecessary tests are not performed can significantly speed up the verification pro- 
cess. 

To meet this end. Vera makes use of constraint-driven random stimulus generation. Borrowing from 
classical signal*processing models. Vera uses a data source and a series of filters to transform and ma- 
nipulate random data feeds into the form required to execute adequate tests. 




f1 











The signal source is a random-number generator, while the filters can be configured to give any chanic- 
teristic required by the data set These facilities lead to test sets that arc easy to understand and straight- 
forward to develop. 

Vera incorporates these stimulus generators into its object-oriented framework, creating a succinct, ele- 
gant, and powerful means of capturing data sets with an intrinsically random structure. Further, as ob- 
jects, multiple stimulus generators can be instantiated and randomized independently. ' 
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Having extended objects to incorporate random variables, Vera also delivers a mechanism for packing 
and unpacking key members of an object. This provides a simple, straightforward mechanism for doing 
the type of data re-organization, such as generating, sending, receiving and analyzing data packets, that 
are common within many test environments. 



9.2 Stimulus Generation Overview 

Vera stimulus generation is divided into two major components: packet generation and data packing. 
Each is used within the object-oriented methodology to facilitate its use and re-use, 

Vera^s random packet generation uses the class constructs within object oriented programming. Qass 
variables normally associated with standard packet generation are declared as random variables. Then 
each instance of the packet generator is randomized by calling Vera's predefined randomization method. 
This enables you to create multiple stimulus generators, randomized separately, using a single genera- 
tion class. 

Once Vera generates random stimuli, these stimuli are then filtered through constraint blocks. Con- 
straint blocks are analogous to signal filters. They control the range of values that randomized variables 
can assume. Their use allows you to narrow the focus of tests to achieve adequate coverage with a max- 
imum efficiency. 

In addition to random packet generation. Vera provides a means to set random variables to all the pos- 
sible boundary condidons. This provides another mechanism with which you can control and direct test 
generation. 

The second component of Vera's automated stimulus generation capabilities is the packing and unpack- 
ing of data into bit streams. Vera again makes use of the object-oriented framework by including class 
methods to handle the packing and unpacking of data. Further, Vera defines several attributes for class 
members that are used to determine how data is packed and unpacked. 

Together, these two components, provide the means to generate and manage randomized data feeds in a 
controlled manner. 



9.3 Random Packet Generation 

Random packet generation is a specific implementadon of Vera's packet generation capabilities. It con- 
sists of two major aspects: random variables and constraint blocks. 



9.3.1 Random Variables 

Variables arc made random using the rand and randc keywords in the variable declaration. The syntax 
to declare a random variable is: 

rand variable; 

randc.^ variable; _ .. - 
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Vera supports the randomization of variables of type integer, bit, and enumerated type. You can also 
randomize objects as well as arrays of integers, bits, enumerated types, and objects. 

Associative arrays can be randomized, but you must specify the size of the array at runtime. For exam- 
ple: 

rand type array^namel] assoc.fiize nxm^bytes} 

numjfytes - NumJ?ytes specifies the number of elements in the array that will be randomized. Note 
that the array size itself can be a random number. You can use elements of the array other than 
those specified, but only the specified elements are randomized, 

9.3.1.1 rand and randc 

Vera has two forms of random variables, which are specified with the rand and randc keywords in the 
variable declaration. 

Variables declared with the rand keyword are standard random variables. Thek values will change ran- 
domly, and repeat values are allowed. 

Variables declared with the randc keyword are random-cyclic variables. A random-cyclic variable takes; 
on all possible values before repeating any value. Random-cyclic variables can only be bit or enumerat- 
ed types, and are limited to a maximum size of 8 bits. This limits the range of values to those falling Ixt- 
tween 0 and 255. 

9.3.1 .2 Active and Inactive Random Variables 

Vera provides the predefined rand_modeO method to control whether a random variable is active or in- 
active. All random variables are initially active. The syntax for the rand_modcO method is: 

oi?ject_name.r«iid_mod«{5vitch variable^name [, index] ]);' 

object name • The object_name is the name of the object in which the random variables arc defined. 

switch - The switch is either OFF or ON. OFF sets the specified variables to inactive so that it 

is not ciiforced on subsequent calls to the randomizeQ method. ON sets the spedfied variables to 
active so that they are randomized on subsequent calls to the randomizeO method. 

variable ^narne^ The variablejtame is the name of the variables to be made active or -. i. jr ^ 
inactive,Thc variable name can be the name of any variable in the class hierarchy. If no 
variable name is specified, the switch is applied to all variables within the specified object 

index • The index is an optional array index. Omitting the index results in all the elements of the anay 
being affected by the call. A *1 index value is treated the same as index omission. 

The rand.modeO method returns the value of smtch (either OFF or ON) if the change is succcssftil. If 
the specified variable does not exist within the class hteFarchy, the method returns a *1. If the specified 
variable exists but is not declared as rand or randc, the function returns a -1, 
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A special case for the switch argument is the REPORT keyword. Using REPORT will return the state 
of the specified constraint (either OFF or ON), The variable name and array index (if the variable is an 
array) must be specified for a REPORT. 

For example: 

class Packet { 

rand integer source_value, dest_value; 
constraint filterl { 

source_value > 2 * m; 

dest_value <= 2 * m + 17; 

} 

} 

Packet packet_a = new; 

integer ret = packet_a . rand_mode (OFF, *source_value- ) ; 
// ... otiher code 

ret = packet_a.rand_inode (ON, •source__value') ; 

This example first makes the variable source j^alue inactive (OFF) and returns OFF to the variable reu 
Then it makes the variable source ji^alue active (ON) and returns ON to the variable ret. 

9.3.2 randomizeO 

Variables arc randomized using the randomizeO class method. The syntax to randomize an object is: 

oi)jF€Ct_naine.randomiro ( ) ; 

■< -> 

object_name - Hie object_name is the name of the object in which the random variables have been 
declared. 

The randomizeO class method generates random values for all random and random-cyclic variables 
within the specified class instance. If there are random objects within the class instance, calling the ran- 
domizeO mediod also invokes their oZyccr.randomizcO methods. Thus, all random variables and ob- 
jects within a random object are randomized when the class instance is randomized. 

When associative arrays are randomized, only elements within the specified range are randotnized. Ele- 
ments outside of this range are not randomized. - ^ . . . 

Random variables declared as static are shared by all instances of the class in which they are declared. 
Each time the randomizeO method is called, the variable is changed in every class instance. 

The randomizeO method returns a 1 if it successfully sets all the random variables and objects to valid 
values. If it does not, it letums a 0, which typically indicates a problem with the constraints. If the ran- 
domizeO call fails, any random variables set vp until the failure retain their setting. If an object has no 
random variables anywhere in its inheritance hierarchy (no random variables or sub-objects) or if all of 
its random variables are inactive, the randomizeO function returns a 1. ~' 



Vera 4.0 User's Manuaf 



Chapter 9. Automated Stimulus Generation 181 



The randomizeO methcMd is implemented using the random() system function. Thus, executing ran- 
domiseed) affects the sequence of random numbers generated by randomizeO • 

For example: 

class Packet { 

local integer sequence; 
local randc bit [5:03 dest_addr; 
protected rand integer erc_addr; 
static rand integer time_origin; 
rand Payload data_part; 

} 

This class definition declares a random-cyclic variable, dest_addr, a random variable, erc^addr, a 
random variable, time^origin, and a random object, data_part . To randomize an instance of class 
Packet, call the randomizeO method: 

int success ; 
Packet p = new; 
success =p . randomize ( ) ; 



9«3«2«1 Randomization Usage Details 

The code for the pre-defined randomize method follows this pattern: 
virtiial function randomize (integer flag = 1) 



{ 



int success = 1; 

if (flag ===1) 

this .pre_randomize () ; 

if (flag ==1) . . ^ . - . 

// Randomize the rand and randc member variables (except 
// nested objects) of ."^tliis* object and all its ancestors, 
// subject, to the active constraints* , , . 

// Set success « JO if it could not find a valid value for one. 

if (success ==1) 

success = super. randomize( 0 ) ; 

v^ile (success 1) 

// For each nested object in "this* th&t is rand, do: 
. , success - nes tecLobject. randomize ( 1 ); ^ f. 

if (flag 1) ' '"'^ ' 

tliis.post_randomize() ; . . ^ , . , - 
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randomize = success ; 



} 

task pre_randomize{) 
{ 

super . pre„randomize ( ) ; 

} 

task post^randomizeO 
{ 



super .post.randomize ( ) ; 

} 

Notice that the flag parameter of super .randomize is 0, so that it will not call pre_raiidonuzeO and 
post.randomizeO- 

Also notice that the non-object member variables of "this" class instance and all its superclasses, back 
to the base class, are randomized at the same time. Random values are assigned in an order determined 
by the constraints, rather than by whether the rand or randc variable belongs to this class or a super- 
class. This allows enforcing a constraint like "super . j < 2 * this . i ; ", where both super . j and 
this . i are random variables, and where super . j can be given its random value only after this . i 
has been given its random value. 

Finally, notice that nested objects are randomized after the non-object variables. This allows variable- 
size arrays of nested objects, since the size of an associative array (as far as packing and randomizing 
are concerned) can depend on one or more random variables. 

You can write your own version of the randomizeQ function. However, if you write your own version 
of randomizeQ for a particular class, the rand and randc variables in the class are not automatically 
set, and any constraints declared as part of the class arc not enforced. 

If your randomizeQ method calls the pre-defined supenrandomizeQ, with the flag parameter set to 
1 (or omitted), the rand and randc variables in this superclass and in its superclasses will be random- 
ized, using the constraints in this superclass and its ancestors, . 

If the class with your randomize() has descendants with the pre-defined randomize ( ) , calling the de- 
scendant's randomize function (with the flag parameter set to 1 or omitted) will affect variables in the 
descendant class and its superclasses, up to but not including the class witii your randomizeQ, using 
the constraints in fliose classes. Your raniiomizeQ will be called, with the flag parameter set to 0. 

The randomizeQ, pre_randomizcQ and post_randomizeQ methods must be public. 



Vera allows you to create lists of objects, which enables you to initialize non-random variables that con- 
strain random variables. 

Tins is an example of using the randomizeQ function on a list of objects: " 



9.3.2.2 Using randomizeQ on Object Lists 
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class ListClass 
{ 

integer id; 
rand bit [3:0] b; 
rand ListClass next; 

task new (integer new„id) 
{ 

id = new„id; 
next = null; 

} 

function IiistClass append_one (integer new.id) 
{ 

next = new (new^id) ; 
append_one = next ; 

) 

// These exanples illustrate the order the list objects 
// are randomized in. 

task pre.randomize ( ) 
{ 

printf(*In ListClass pre.randoxnize: object %Od\n*, id); 

} 

task post„randomize ( ) 
{ 

printf(*In ListClass post.randomize: object %0d: b is %Oh\n'',id, b) ; 

} 

task print^listO 
{ 

printf CListClass object %0d; b is %Oh\n", id, b) ; 

if (next null) next.print_list () ? ' . 

} 

} 

task DoListO 
{ 

integer i = 1; 
integer success; 
ListClass head, tail; 

// Create a list of objects with sequential id's, 
head = new( i++ ) ; 
tail = head.append_one( i++ ); 
tail = tail.append^one( ); 
tail = tail,Bppend_one( i++ ); 
tail = tail.append»one( i++ ); 
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// Show the list, with variables not yet randomized. 

printfCIn DoList, the list before randomization is:\n"); 
head.print_list ( ) ; 
printf ("\n") ; 

// Invoke randomize on the head of the list. It will randomize 
// any non-object member variables ("b" in this example), then it will 
// invoke randomize on any object member variables ("next* in this 
// exait^le) , This will be repeated automatically until it encounters 
// the tail of the list, where "nexf is null, 

success = head , randomize ( ) ; 

if (success != OK) printfC randomize failed in DoListVn*); 

// Show the list, with variables set to random values, 
printf ( • \nThe list after randomization is:\n'); 
head . pr int_l is t ( } ; 
printf CNn') ; 



9.3.2.3 Using randomizeQ to Create Arrays of Variable Size 

Vera allows associative arrays, which can have very large indexes despite being a sparse array because 
elements are created when they are referenced. However, if an associative array is declared to be ran- 
dom, the number of its elements that are assigned values by the randomizeQ function must be speci- 
fied. This expression can include random variables. Note that with this sctup^ constraints should be set 
up to force a non-negative value. 

This is an example of using randomizeQ to create an array of variable size: 

fdefine FACTOR 2 
tdefine ORDINARY.SIZE 3 
♦define MAX_SMALL_ARRAY„SI2E 7 

class SmallClass 
{ 

rand bi t [ 2 : 0 ] sinall_var ; 

} 

class ArrayClass 
{ 

// All these variables are random, 
rand 
{ 

integer m, n; 

integer ordinary [ORDIKARyIsizE] ; // ordinary array ^ 
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bit [7:0] b„array [] assoc_size FACTOR * in;// associative array 
SjnallClass small^array [] assoc_size n; // assoc, array of objects 

} 

// Constraint blocks are class members, just as the properties 
// (variables) and methods (tasks and fiinctions) in a class are 
// class members. Constraints must follow the variables, 
// but come before the tasks and fxinctions, of a class. 

constraint size.cons 
{ 

m >= 0; m <= 3; 

n >= 1; n < MAX_SMALL_ARRAy„SI2E; 

} 

task new() 
{ 

// Objects must be instantiated before they can be randomized- 
// Here, instantiate the maximum nuniber of SmallClass objects 
// that might be randomized in small_array, 

integer i; 

for (i = 0; i < MAX_SMALL_ARRAY„SIZE; ++i) 
small„arrayli3 = new; 

} 

task print_array() 
{ 

integer i ; 

printf Cm is %0d, n is %Od\n", m, n) ? 
for (i 0; i < ORDINARY_SIZE; ++i) 

printf ('ordinary C%Od] is %Od\n', i, ..ordinary Ci] ) ; 
for (i s= 0; i < FACTOR * m; ++i) 

printf (■b_array[%Odl. is %h\n', i, b.arrayti]); 
for (i 0; i < n; , 

printf ( • smal l^array I % 0 d 3 . small_var is %b \n • , i , 
smal l_array [ i 3 , smal l_var ) ; 

} 

} 

task DoArrayO 
{ 

integer succes s ; 
ArrayClass a; 

a = new ( ) ; 

success = a.randomizeO ; • 
if (success I = OK) printf ( "randomize failed in I3oArray\n" ) ; 
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printf ("In DoArray^ ArrayClass values after randomize () call.'Xn"); 
a -print_array ( ) ; 
printf CXn-} ; 

} 

9.3.3 Constraint Blocks 

The values of random variables can be controlled using constraint blocks. Constraint blocks limit the 
set of legal values that random variables can assume. These constraints arc enforced by the random- 
izeO class method. 

Constraint blocks arc class members. They arc defined within the class to be randomized. They must be 
defmed after all the variable declarations in the class and before all the task and function declarations in 
the class. The syntax to declare a constraint is: 

constraint constraint^name { contraint_expressions ) 
constrcuntjiame - The constraint^name is the name of the constraint blocL 

constraint jexpression - The constraint_expressions are the conditional expressions that limits random 
values. It is a series of expressions that are enforced when the class is randomized. Constraint 
expressions are of the form: 

random_variahle operator expression; 

random_variable - The random_variable parameter specifics the variable to which the constraint is 
^plicd. 

operator - The valid operators for constraints are: <, <=, =, >=, >, !=, =, !=» =?=, and !?=. You can 
also use in, !in, and dist for distribution sets. 

expression - The expression parameters can be any valid Vera expression with the following exceptions: 
You cannot call a task or function. 

• Pre- and post-operators, like are not allowed. 

^ If the random variable is cyclic, the expression cannot contsdn any random variables. 

• Cyclic constraints are not allowed (for example, A < B; B < 2 * A). 

• The specified random variable cannot appear on both sides of the expression. 

• The specified random variable must be' a member of this class or one of its 
antecedents. 

• Expressions cannot include nested objects of this class, its superclasses or 
descendants - to preclude recursion. 

• Expressions cannot include random member variables of nested objects. 

If constraints in different classes in the inheritance hierarchy have the same name, the constraint in the 
lowest level descendant is used. 



This is an example of a basic constraint block: 
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class Packet { 

rand integer source„value; 
constraint filterl { 

source^value < n + 3; 

source_value > 2 * m; 

} 

} 

Tliis example defines a class Packet, declares the random variable source jpohie, and defines the con- 
straint block filterl. Tlie constraint block filterl limits the range of values of source_value to 
those values falling between (n+3) and {2*m), where n and m are arbitrary global variables, 

9.3-3.1 Distribution Sets 

Distribution sets specify ranges of values and may assign weighted probabUities to them. The syntax to 
define a distribution set is: 

variable command {ranges}; 
variable - The variable is the random variable, which is controlled by the constraint 
command - The command can be in, !in, or dist 

ranges - Each of the ranges is a range of values specified by Vera expressions. Ranges are defined by 
specifying a low and high value, separated by a colon (:). If only a single value is specified, the 
range exists only of that value. Multiple ranges can be declared in the same, definition using 
commas to separate them. For example: 
data_addr in {5:7, 10, x+3:y*2>; 

Expressions must follow the same rules random expressions follow regarding operators and variables. 

Note - A random variable can have only one distribution set (in, !in, or dist) 
associated with it 



in and !in 

The in coiiimand limits the values of the specified random variable to those within the defined ranges 
For example: 

data_addr in {1:4, 6, 8:10); 
Hiis example declares a constraint such thai the only values that data.addr can assume arc 1 to 4, 6, 
and 8 to 10. 

An alternative to the in command is the !in command. The !in command specifies ranges of values tliat 
the random variable cmnot assume. For example: 

data^addr !in {1:4, 6, 8:10); ^ 
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This example declares a constraint such that data_addr can assume all values except 1 to 4, 6, and 8 
to 10, 

dist 

The dist command limits the values of the specified random variable to those within the defined range, 
and it assigns weighted probabilities to the values. The dist command uses two operators to assign 
weights: := and :A 

The := operator assigns the weight to each element in the list The zf operator distributes evenly the 
weight across the values of the range. For example: 

data„addr dist {5:7 := 10, 9 ;= 20}; 
data_addr dist {5:7 :/ 60, 9 :/ 40}; 

The first declaration assigns a weight of 10 each to 5, 6, and 7, and it assigns a weight of 20 to 9, The 
second declaration distributes a weight of 60 across the range 5:7, which assigns a weight of 20 each to 
5, 6, and 7, It also assigns a weight of 40 to 9. The probability that any single value is assigned to the 
variable is the individual weight divided by the total weight of the distribution. For example, using the 
first declaration, the probability that data_addr is assigned a value of 5 is 10/50 or 20%. 

9.3.3.2 Constraint Errors 

If constraints are set such that they can never be satisfied, a hard error occurs and the simulation termi- 
nates. This occurs with conflicting constraints that do not contain random variables or distribution sets 
that have no valid entries. 

If constraints that contain random variables cannot be satisfied, a soft error occurs. A 0 is returned and 
the simulation continues. A subsequent call to the randomizeO method may change the constraint vari- 
able, and the check is made again. 

In several cases, constraints that can never be satisfied are treated as soft errors. These include: =?=, 
in, lin, and dist constraints. 

9.3.3.3 Active and inactive Constraints 

Vera provides the predefined constraiiit_modcO method to control whether a constraint is active or in- 
active. All constraints are initially acdve. The sj^ntax for the constraint^modeO mediod is: 

objGC t_name - coiuitraint_fflod« ( sari tch i , cons train t^name] ) ; 

object name - The object^name is the name of the object in which the constraint block is defined. 

switch - The switch is either OFF or ON. OFF sets the specified constraint block to inacdve so that it 
is not enforced on subsequent calls to the randomizeO method. ON sets the specified constraint 
block to active so that it is enforced on subsequent calls to the randomizeO method. 
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constraint jiame - The constraint jname is the name of the constraint block to be made active or 
inactive.The constraint name can be the name of any constraint block in the class hierarchy. If no 
constraint name is specified, the switch is applied to all constraints within the specified object. 

The constraint^modeO method returns the value oi switch (either OFF or ON) if the change is suc- 
cessfiiL If the specified constraint block does not exist within the class hierarchy, the method returns sl 
-1. 

A special case for the switch argument is the REPORT keyword. Using REPORT will return the state 
of the specified constraint (either OFF or ON). The constraint name must be specified for a REPORT. 

For example: 

class Packet { 

rand integer source_value; 
constraint filterl { 

source_value > 2 * m; 

} 

} 

Packet packet„a = new; 

integer ret = packet_a. cons train t_mode (OFF, filterl); 
// ... ot±er code 

ret = packet_a. const rain t_inode (ON, filterl); 

This example first makes constraint filterl inactive (OFF) and returns OFF to the variable ret. Then 
it makes constraint filterl active (ON) and returns ON to the variable ret, 

9.3.3.4 Void Constraints 

Vera allows you to assign a void value to constraints, which is useful using conditionals. The syntax is: 

rando2H_ variable operator {conditional) ? expression : void; 
condidonal - The conditional can be any valid constraint expression. 

If the conditional evaluates to true, the constraint is set to die specified expression. If the conditional 
evaluates to false, the constriiint is made void, and the random variable is not affected by this con- 
straint Note that it could be affected by other active constraints. 

This is an example of several constraints used togethcn 



rl 


>= 


(r2==0} 


? 


1 


: void; 


rl 


>= 


(r2==:l} 


? 


2: 


void; 


rl 


>= 


(r2==2) 


? 


4: 


void; 


rl 


>- 


(r2=:=3) 


? 


8: 


void; 


rl 


>= 


(r2>3) 


? 


16: 


void; 



This exanq)le sets rl greater than or equal to lif r2 is equal to 0, If r2 is equal to 1, ri is set so that it 
is greater than or equal to 2. The progression continues through all of the conations. 
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9.3.3.5 Static Constraint Blocks 

You can define a constraint block as being static by including the static keyword in the definition. The 
syntax to declare a static constraint block is: 

static constraint constraint_ziame { contraint^Gxpression } 

If a constraint block is declared as static, calls to constraint_modeO affect all instances of the specified 
constraint in all objects* So if a static constraint is set to OFF, it is OFF for all instances. 



9.3.3.6 Constraint Interdependencies 

In Vera, a constraint has a single random variable on the left side of an operator. Tlie expression on the 
right side of the operator may include other random variables. The randomizeQ function sorts the ran- 
dom variables before randomizing to ensure that a random variable on the right side of a constraint has 
been assigned a value before assigning values to variables that depend on those constraints. 

This is an example of using constraint interdependencies: 

#define NUM„R 9 
class Cons traintC lass 



{ 



rand integer r[NUM„R]; 

constraint conl 

{ 

// r[l] and r[2 3 will be assigned values before r[03 
r[0] >= rEl] + 2 * rt23; 
r[13 > 0; . 
r[l] < 10; 



// r[3 

r[2 
r[3 
r[3 
r[4 
rI4 
r[5 
rl5 

// r[7 

r[6 
r(8 
r[8 



r(4], rE5], r[81 will be assigned values before r[23 

in { rI33 : r[33 4, r[43 - 2 : r[53, r[81 }; 

> 0; ' ^ . .. 
'<,5; . 

> -20; , - . , . . 

< -10; 

> 3; 

< 12; 

and rC83 will be assigned values before r[63 

== r[73 / r[8]; 

> 1; 

< 5; 



// r(83 will hG assigned a value before rt7] 
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r[7] > r[8]; 

} 

task print_vars(} 
{ 

integer i; 

for (i = 0; i < NUM_R; ++i) 

printf ("r[%Od] is %d\n* , i, r(i]); 

} 

} 

task DoConstraint ( ) 
{ 

integer success; 
ConstraintClass c; 

c = new ( ) ; 

success = c . randoioize ( ) ; 

if (success != OK) printf( "randomize failed in DoConstraintXn'} ; 
printf(*In DoConstraint, ConstraintClass values after randomize () 
call:\n") ; 
c . pr int^vars < ) ; 
printf CXn') ; 



9.3.3.7 Dynamic Constraint Modification 

There are several ways to dynamically modify constraints on randomization: 

• Within a constraint, the ?: construct can be used like an if statement to indicate 
which of two values should appear on the right side of the constraint 

• A constraint block can be made active or inactive by using the constraint_madeO 
function. Initially, all constraint blocks are active. Inactive constraints arc ignored by 
the randomizeO fimction. 

• Random variables can be made active or inactive using the rand_modeO function. 
Initially, all rand and randc variables are active. Inactive variables are ignored by 
the randomizeO function. ? ^ 

• The weights in a dist constraint can be changed, affecting the probability that 
particular values in the set are chosen. 

This is an example of dynamically modifying constraints: 

class DynamicClass 
{ 

bit I S : 0 ] counter ; 
rand { 

bit [7:0] byte; 

bit [3: 03 nibble; 
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bit [15:0] half-word; 
bit [31:0] word; 

} 

// If counter is > 10, randomize will give nibble a value tliat 
// satisfies 'nibble =?= 4'blOxx''. If not, randomize will give 
// nibble a value that satisfies •nibble =?= 4'bOxxl", 

constraint con^question 
{ 

nibble =?= ( (coxinter > 10) ? 4'blOxx : 4'bOxxl ); 

) 

#ifdef VEKA.4_0 

// If nibble is 0, randomize () will produce a value for byte that 
// satisfies 'byte 3", that is, it will set byte to 3. 
// If nibble is 1 or 2, it will set byte to 5, 

// If nibble is 3 or 4, it will set byte to (nibble | 4'blOOO) . 
// If nibble is between 5 and 8, it will set byte to 7. 
//If nibble is greater than 8, it will set byte to a random value 
// less than 12. 

constraint con_void 
{ 

byte == ( (nibble ==0} ? 3 : void ); 

byte == ( (nibble :== 1 | | nibble === 2) ? 5 : void ); 

byte === ( (nibble == 3 | 1 nibble 4) ? nibble | 4'blOOO : void ); 

byte == ( (nibble >- 5 && nibble 8) ? 7 : void ); 

byte < ( (nibble > 8) ? 12 ; void ); 

} 

#endif 

// The next two constraint blocks conflict with each other — that is, 
// there is no possible value for word that can satisfy both con_zero 
// and con- ones. The caller will make, sure that, only, one of these two 
// is active at a time, 

constraint con_2ero 

{ ' ' " ■ 

word =?= { half_word, byte, nibble, .4*b00xx >; 

} 

constraint con_ones 

{ , : 

word =?= { half_word^ byte, nibble, 4'bllxx }; 

} 



— 
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task new() 
{ 

coiinter = 0; 

} 

// The pre_randomize ( ) task itself will modify counter, which will 
// affect which constraints apply to the random variables. 

task pre_randomize() 
{ 

++co\mter; 



printf( "counter is %d\n", counter); 
printf ( •half-word is %h\n* , half-word) ; 
printfCbyte is %h\n" , byte); 
printf (•nibble is %h\n" , nibble); 
printf ( "word is %h\n*' , word) ; 

} 

} 

tdefine LOOP_MAX 20 

task DoDynandcO 
{ 

integer i, j, success; 
DynamicClass d; 
d = new ( ) ; 

// One of the two conflicting blocks must be made inactive. 
// After half of the loop iterations below are completed, this 
// one will be re-activated and the other one made inactive. 
// (Calling cons train t^iaode (OFF) will return OFF \inless it is 
// unable to find a constraint block with the specified name, 
// e.g. due to a spelling error.) - ' - 

xt (d.constraintjaode (OFF, •condones") 1- OFF) , 
_ printf (■ cons traintjaode( OFF) failed on con_ones\n') ; 
printf ('In DoDynamic, turned condones constraint OFF.\n\n*J; 
for (i = 0; i < LOOP.MAX; ++i) 
{ 

success = d.randomizeO ; 

if (success != OK) printf (• randomize failed in DoDynamic, i %Od\n*,i); 



} 



task print_vars() 
{ 



printf (•DynamicClass values after randomize () call with 
^^i=%Od:\n-,i); - . ^; - '^ : 

"d.printjirars(); ' * ' ^ ^ * u . 
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print f CVn"); 

if (i == LOOP_MAX / 2) 

{ 

if (d,constraint_mode (ON, "condones") 1= ON) 

printf <''constraint_mode{ON) failed on condones \n* ) ; 

if (d.constraint_mode (OFF, •con_zero") != OFF) 

printf (•',constraint_mode(OFF) failed on con_zero\n*) ; 

printf ("\nTumed condones constraint ON, cbn_zero OFF-\n\n*); 

} 

} 

fifdef VERA_4_0 

// Now inactivate all the random variables, leaving them at whatever 

// values they now hold, except "nibble". Any constraints with inactive 

// random variables on the left side are ignored. 

if (d.rand.mode (OFF) != OFF) 

printf (• rand-mode (OFF) f ailed\n" ) ; 
if (d.rand_mode (ON, "nibble") i= ON) 

printf ("rand-mode (ON) failed on nibble\n"); 
printf ("XnTumed all random variables except nibble OFF.\n\n"); 
for (j = 0; j < 4; ++ j ) 
{ 

success = d.randomizeO ; 

if (success != OK) printf ("rcindomize failed in DoDynamic, j %Od\n",j); 
printf ("DynamicClass values after randomize () call with 
j=%Od:\n", j); 
d.print_vars ( ) ; 
printf CXn"); 

) 

#endif 

} 

9.3.4 Boundary Conditions 

Vcra's boundary condition capabilities arc used to generate values that match the upper and lower limits 
of a random variable's valid value range. This is particularly useful because many design flaws occur at 
the boxmdary conditions. Boundary conditions are generated when the system function boundaryO is 
called. The syntax to call the boundaryO function is: 

object_name •bofundaxy ( which ) ; 

ohjeci^name - The object jname is the name of the object on which the boundaryO call is being made, 

which - The which argument must be cither FIRST, which sets the effected random values to their first 
' boundary condition, or NEXT, vdiich cycles through each subsequent boundary condition^ 
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Boundary conditions for random variables are determined by the constraints on a random variable. For 
instance, examine this constraint block: 

class foo { 

rand integer a, b, c; 
constraint cl { 

a>=10; a<=20; 

b>=0; b<=100; 

c in {1:15, 32:63}; 
> 'I J 

} 

For this constraint block, a has the boundary conditions 10 and 20, b has the boimdary conditions 0 and 
100, and c has the boundary conditions 1, 15, 32, and 63. This results in 16 different boundaxy condi- 
tion combinations that would be generated with the boundaryO system function. 

The boimdatyO method treats rand and randc variables the same way. Note that you can also use ran- 
dom variables within the constraints so that boundary conditions are dependent on random values. 
However, if the values of the right-hand side of a constraint change while the boundaryO method is be- 
ing invoked, the boundary conditions are determined by the values at the time of the function call. Sub- 
sequent changes to the conditions do not affect the current call, but they will affect future calls. 

When the boundaryO function is called, all random variables within the specified class instance are set 
to their boundary conditions. If the w/ucA argument is set to FIRST, the first set of boundary conditions 
arc used. If the which argument is set to NEXT, the next set of boundary conditions in the sequence is 
used. The sequence of boundary conditions is influenced by a number of factors, including the order of 
variable declaration and the order they are named in the constraints. 

If there arc random objects within the class instance calling boundaryO, it also invokes o&jcct.bound" 
aryO- Thns^ nested objects and extended classes are affected by calls to boundaiyO- Random variables, 
declared as static are shared by all instance of the class in which they are declared. Each time the 
boundaryO method is called, the variable is changed in every class instance. 

When the boundaryO function is called, it returns a 1 (or OK) each time it successfully sets the'randoiri 
variables to their boundary conditions. If one or more variables cannot be set due to conflicdng re- 
straints, it returns a 0 (or FAIL), If the last set of conditions has been set, it returns a 2 (or OKiLAST). 
If an object has no random variables anywhere in its inheritance hierarchy (no randpm varisWfts or sul>- 
objects) or if all of its random variables are inactive, the boundaryO function returns a NO JVARS. 

The boundaryO function makes calls to pre.boundaryO and post_boundaryO much in the same way 
that randomizeO calls pre^randomizcO and post_randamizeO. 

This is an example of the boundaryO system function: 

program b 
{ 

integer success; 
itty_object obj = new; 

Synopsyslnc. 
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success = obj .boundary (FIRST) ; 

while (success==OK) success = obj .boundary (NEXT) ; 

if (success !=OK_LAST) printf ( *Bo\mdary problem (%Od)\n"', success); 

} 

This example defines the object obj . Hie random variables within obj are set to their initial boundary 
conditions with the first boundaryO call. The while loop sets them to their other boundary conditions. 

9.4 Data Packing and Unpacking 

Data packing consists of the packing of data fields into a serial bit stream and the subsequent unpacking 
of the bit stream to re-form a data structure. Data packing is particularly useful for sending packets over 
serial communication streams and then converting back to a packet structure. 

Again, data packing is integrated into the object-oriented framework of Vera. Vera defines several class 
methods that are used to pack and unpack data. Vera also provides a set of attributes for class members 
that designate how data is to be packed and unpacked. 

There are two main aspects of data packing: property attributes and the pack and unpack class methods, 

9,4.1 Property Attributes 

Vera provides several property attributes that designate how data is to be packed and unpacked. These 
attributes include: 

• little-endian 

• big_endian 

• bit_nonnal 

• bit„reverse 

• packed 

• unpacked i 

The attributes Little-endian, bit.endian, bit.normal, and bit.revcrse can only be assigned to vari- 
ables also assigned the packed attribute. These attributes can only be assigned to class variables; they 
cannot be assigned to class methods or constraints. 

When variable attributes arc nested, the lowest level attribute overrides the higher level attributes. For 
example: 

packed bit^reverse " " 
{ 

integer i ; 

bit_nonnal string str; 

unpacked 

{ 

integer k; ~ ' 
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) 

integer n; 

} 

In this example, i and n are packed bit^reverse, str is packed bit.normal, and k is unpacked, 
little-endian 

Variables assigned the little_cndian attribute are packed least-significant byte first This is part of tlie 
default attribute settings. 

big-endian 

Variables assigned the big_endian attribute arc packed most-significant byte first 
blt_normal 

Variables assigned the bit.normal attribute are packed most-significant bit of each byte first Tbis h 
part of the default attribute settings. 

bit_reverse 

Variables assigned the bit„reverse attribute are packed least-significant bit of each byte first 

9.4.2 Packing Methods ' ^ 

The pack and unpack methods can be used to pack member variables of type integer, bit field, string, 
enumerated type, and objects into an associative array of type bit, and vice versa. Strings arc packed as 
a sequence of bytes, with a zero-byte terminator. Uninitialized or unknown integers are packed as 32 
bits of *x\ Enumerated types are packed in up to 4 bytes. An associative array must have a size field 
specified before it is packed. Anything not within the size specification is not packed. ^ 

The syntax to pack data is: ^ 
object_na2ne .pack (array, index, left, right); 

array - The array parameter specifies the array into which data is to be packed. The array can be an 
associative array of any bit width. . ^ 

index - Tbc index parameter specifies the array index at which to start packing. 

left/right - The left and right parameters specify the number of bits on the left and right to leave 
unchanged in array{index\. Normally, you initialize them to 0 before calling packQ* 

The packO method returns the number of bits packed. It also updates offset, left, and right so that they 
can be used as arguments to subsequent packQ calls when packing multiple objects into a single 
stream. 

This is an example of die packQ method: 
Synopsys Inc* 
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integer nbits; 
integer offset = 0 ; 
integer left = 0 ; 
integer right - 0 : 
bit [7:0] streamEl; 

nbits = packet_head, pack (stream, offset, left, right); 
nbits+ = packet_body .pack (stream, offset, left, right); 

When the packQ method is called, it begins by packing the first member it encounters. If an object's 
handle is encountered, then the packQ method of that class is invoked. Packing an object handle that is 
null produces a warning, and nothing is packed for that nested object; that object handle should also be 
null when the containing object is unpacked. If a nested object's handle is not null when it is packed, 
the handle should also be non-null before it is unpacked; tmpacking does not call new to create objects. 

9.4.3 Unpacking Methods 

The unpacking methods are analogous to the packing methods. The syntax to unpack data is: 
oJbject_najne.tanpack (array, index, left, rigrht) ; 

The parameters have the same definitions as with packQ. The array parameter should be set to the ar- 
ray into which data was packed. The index, left^ and right are normally initialized to 0. Hiey are then 
updated with each call to impackQ. This allows you to unpack multiple objects from a single array. 

You should generally impack multiple objects from one array in the same order in which they were 
packed. For example: 

x.pack( . , , ) ; 
y. pack {,..); 
z . pack (.-,); 
X . unpack (...); 
y - unpack ( ) ; 

z. unpack ( . . , ) ; ™ ^ 

9.4.4 Pack and Unpack Example 

This is an example of the packQ and unpackQ methods: 
# inc lude <vera_de fines . vrh> 
class Serial„Data_Type 

static integer inst jum = 0; 

packed 

{ 

Synopsi& Inc. 
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rand bit [19:0] bit_data; 
s t r ing c ommen t ; 

} 

task new() 
{ 

integer status; 

status = this - randomize ( ) ; 
if { ! status ) 

error ( •Randomize failed! \n" ) ; 
inst_ixum++; 

sprintf (coxnment, "This is serial packet instance ntraiber %0d having 
data %b « , inst_num, bit_data ) ; 
}//end task new 

} 

program packed^test 
{ 

Serial_Data_Type sdata_arr [5] ; 

bit data_streain[3 ; // does not have to be byte stream 
integer i, g_offset, g^left, g_right; 

printf ( • \n\nPacking data \n" ) ; 

g„offset = 0; g_left = 0; g_right = 0; 

for ( i = 0; i < 5; i++ ) 

{ 

sdat a_arr [ i 3 = new ; 

printf "<* %s \n*, sdata^arrCi J .comment ); 

void = sdata.arr Ci] *pack ( data_stream, g_offset, g_left, , 



g_offset = 0; g_left = 0? g_right = 0; 

for ( i = 0; i < 5; i++ ) 

{ 

void = sdata_eu:r[i] .unpack ( data_stream, g.of fset, 

g_lef t, g^right ) ; 
printf (• %s \n', sdata„arrli] .comment ); 
}//end for 



g_right ) ; 
>//end for 

printf ( ■ \nVnUnpacking data in order 



\n-) ; 



} 



9.4.5 



Details of Pack and Unpack 



The code for the pre-defined packQ method follows this pattern: 
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virtual function integer pack (var bit[N:0] array [], 

var integer offset, var integer left, var integer right, 
integer flag = 1) 

{ 

integer nbits = 0; 

if (flag == 1) 

this ,pre__pack ( ) ; 

nbits = super, pack (array, offset, left, right, 0); 

// code to pack the member variables of 'this" that are marked packed 
// — in order, including nested objects — adding to nbits 

if (flag == 1) 

this .post jack ( ) ; 

pack = nbits; 
task pre_pack() 

super . pre_pack ( ) ; 
task post_pack() 

super . pes t_pack ( ) ; 

Notice that the pack method calls the pack() of its superclass before packing member variables of the 
current class. Then, unless the superclass's packQ method has been overridden, it calls its own super- 
class's packQ. Thus, the packing operation ultimately begins with the base class and works its way 
down the hierarchy, so that data associated with the base class is packed before data associated with its 
descendants. Notice also that the jlag parameter of super .pack is 0, so that it does not call pre^packQ 
and postjackQ. 

The unpackO, prejpackQ, and post_j)ackO methods follow this siame pattern. Each of these methods 
must be public. 

If you override the pre-defined method, you must specify a particular bit width, which will be inherited 
by all the class's descendants. 
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Example 4: Stimulus Generation 

This is an example using automated stimulus generators. The example includes these features;: 

• Random packet generation 

• Constraints 

This example includes these files: 

• globaldefM 

• memCtUfvrh 

• stimgetuvr 

• RUN (a run script) 

The RUN script generates a header file for stimgen.vr, 

globaidef.h 

tifndef FILE_GLOBALDEF_H 
tdefine FILE_GLOBAIiDEF_H 

enum MEM_SEG = MEM_SEGO, MEM_SEG1, MEM_SEG2 ; 

enuin COVERAGE_VAI/„OPT = GENERIC_COV, STATE_COV, TRANS_COV; 

#define W_NOOP 1 
#define W_FLUSH_CACHE 2 
#define W_BURST.READ 8 
tdefine W_SINGLE_READ 4 
#define W_BURST_WRITE 7 
tdefine W_SIKGLEJMRITE 3 

tendif 

memCtlJf.vrh 

tifndef INC_MEMCTL_IF_VRH 
tdefine INC_MEMCTL„IF_VRH 
tdefine INPUT_EDGE PSAMPLE 
tdefine OUTPUT^EDGE PHOLD 
tdefine 0UTPUT_SKEW tl 
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interface memCtl 
{ 

input [3:0J mc_state INPUT„EDGE ; 

inout [2:0] and INPUT.EDGE OUTPUT_EDGE OUTPUT„SKEW ; 
inout cache_hit INPUT_EDGE OUTPUT_EDGE OUTPt7T„SKEW ; 
inout cache_dirty IKPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
input elk CLiOCK; 
) // end of interface memCtI 

port mport 
{ 

inc_state; 
cnid; 

cache_hit; 
cache_dirty; 
>//end nport 

bind ir^ort mbind 
{ 

itic_state inemCtl.mc_state; 
cmd memCtl-cmd; 
cache„hit memCtI . cache_hit ; 
cache_dirty memCtl*cache_dirty; 
}//end bind 

#endif 

stimgen.vr 

# inc lude <vera_de fines . vxh> 
# include •memCtl.if . vrh" 
# include 'globaldef -h' 

// Random Obj t„Addr 

// consists of random type members concerning the address values 

// the 3 constraints have to be exclusively turned on, to select 
// the value of address being generated, otherwise, it will 
// give error of conflicting constraints 

class t_Addr 
{ 

rand bit (15:0] tag; 
ratndc bit (7:0] cache_idx; 
constraint addr_segO_con 
{ 
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tag >= 16'hOOOO ; 
tag < 16'h0100 ; 

} 

constraint addr_segl_con 



{ 



tag >= 16'h0100 
tag < 16'h0200 



> 



constraint addr_seg2_con 
{ 

tag >= 16'h0200 ; 
tag < 16'li0300 ; 

} 

}//end class t_Addr defn 

// Random Obj which contains t_Addr type of obj as meinber 

// members include the t_Addr type obj, cache.hit, cache_dirty 

// member methods include 

// gen_addr : do a randomize on the addr obj 

// incre_addr : increase the addr value 

// €xec_cmd : execute the command type 

// test_boundary : test all boundary conditions with a 

// certain segment with a certain command 

class t_CmdPacket 
{ 

// Non-Rand Stuff 

bit [2:0] command; 

// rand members 

rand 
{ 

t_Addr mem^addr; 

bit stiiiL.cache_hit; . . 

bit stinucache„dirty; 

} 

local task drive_memCtl with mport {); 
task new ( ) ; 

task gen^addr ( MEM^SEG which^^enuseg ) ; 
task incre_addr ( ) ; 

task test_boundary with mport (MEK_SEG which_mem_seg,bit [2 : 03 do_cmd) ; 
task exec_crod with iE?)ort( bit (2:0] do_cmd) ; 
}//end class t.CmdPacket .defn 
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task t_CxndPacket : : new ( ) 
{ 

inein_addr = new; 

} 

task t_CmdPacket : : gen_addr ( MEM„SEG which_inem_seg ) 
{ 

integer status; 

case < which_ineni_seg ) 

{ 

MEM_SEGO : 
{ 

vo id = inem_addr . cons traint_inode ( ON , • addr_s egO_con • ) ; 
void = inem_addr.constraint_mode ( OFF, ■addr_segl_con" ); 
void = mem_addr.constraint_mode { OFF, •addr_seg2_con* ); 

} 

MEM_SEG1 : 
{ 

void = mem_addr.constraint_mode ( OFF, •addr_segO_con' ); 
void = inem_addr.constraint_mode ( ON, "addr_segl_con* ); 
void = ineia_addr.constraint„mode ( OFF, •addr_seg2_con* ); 

} 

MEM_SEG2 : 
{ 

^ void = mem_addr.constraint„mode ( OFF, •addr_segO_con'' ); 
void = inem_addr.constraint_mode ( OFF, •addr_segl_con" ) ; 
void = mem_addr, cons train t_mode ( ON, •addr_seg2_con" ) ; 

} 

}//end case 

status = this . randomize () ; 
if ( status == 0 ) 

error ("Randomize failed! \n"); 
}//end gen_addr 

task t_CmdPacket: :test_bo\indary with xi?)ort (MEICSEG which_pienu.seg, 
bit C2:0] do_cmd) 

{ 

integer status; 

case ( which_men^seg ) 

{ 

MEM_SEGO : 
{ 

void = menL_addr,constraint_mode ( ON, "addr^segO^con* ) ; 
void = meixL-addr.constraintjaode ( OFF, . •addr_segl_con" ); 
void - mem_addr.constraint_inode ( OFF, ■addr_seg2_con' ) ; 
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} 

MEM_SEG1 : 
{ 



void = mem_addr. cons train t_mode 
void = inem„addr,constraint_mod€ 
void = mem_addr.constraint_iaode 



( OFF, 



( OFF, 
< ON, 



■ addr_s egO_con " ) ; 
"addr_segl_con" ) ; 
•addr_seg2_con* ) ; 



} 

MEM_SEG2 : 
{ 

void = inem_addr.constraint_mode { OFF, •addr_segO_con* ); 
void = mem_addr.constraint_mode { OFF, •addr_segl_con" ); 
void = «iem_addr.constraint_mode ( ON, "addr_seg2_con* ) ; 

} 

}//end case 

status = this.lx>undary (FIRST); 

if { status != FAIIi €c& status OK.IAST ) 

exec_cmd with (get_bind()) ( do_cmd ); 
else 

error ("unexpected failure in boundary call!\n*); 
while ( this. boundary ( NEXT ) i= OK„LAST ) 
exec_cmd with (get_bind()) ( do_cind ); 
} / / end tes t_boundary 

task t_ClndPacket : : incre^addr ( ) 
{ 

this . icieiti_addr * tag = 32; 
}//end incre_addr 

task t„CmdPacket: :exec„cmd with inport ( bit 12:0) do_cmd ) 
{ 

integer status; 
this, command = do_cmd; 
drivejaemCtl with (get_bind()) (); 
}//end task exec_cmd 

task t_CmdPacket: : drive jnemCtl with inport () 
{ 

ei $cmd = this.cotnmand; 
60 $cache_hit = this.stinucachejiit; 
SO $cache_dirty = this.stim.cache^dirty; 
ei $mc_state == void; 
}//end task drive_memCtl 
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RUN 

#!/bin/csh -f 

rm -f *,vro core *.vshell >& /dev/null 
vera -cnqp -g -h stiingen.vr 
if <$status) exit 1 




Synopsys Inc.; 



Vera 4.0 User's Manual 



Chapter 1 0- Vera Stream Generator 207 



10. Vera Stream Generator 

This chapter mtroduces the Vera Stream Generator, It describes the powers of the VSG and details its 
use. This chapter includes these sections: 

• VSG Overview 

• Production Definitions " 

• Production Controls 

• Value Passing 

10.1 VSG Overview 

The syntax for programming languages is often expressed in Backus Naur Form (BNF) or some deriv- 
ative thereof. Parser generators use this BNF to define the language to be parsed, Howcvct, it is possi- 
T)lc to reverse the process. Instead of using the BNF to check that existing code fits the correct synta^c, 
the BNF can be used to assemble code fragments into syntactically correct code. The rw^^^^ the gen- 
eration of pseudo-random sequences of text, ranging from sequences of characters to syn'tacUcally and 
semantically correct assembly language programs. . . 

Vera's implementation of a stream generator, the VSG, is defined by a set of rules and productions en- 
capsulated in a randseq block. The general syntax to define a VSG code block is: -^v - 

randseq {production_name) { 

product! on^defini tionl ; 

production_definition2s 

, .... , _ 

product iozi^dGfini tioziN; 

When the randseq block is executed, random production definitions arc selected and stieincd together 
to generate a random stream. How these definitions are generated is determined by the base^clements 
included in the block, -v- \r*^ 

Any VSG code block is comprised of production definitions. Vera also provides weights, production 
controls, and production system functions to enhance production usage. Each of these VSG components 
is discussed in detail in subsequent sections. 



10,2 Production Definitions 

A language is defined in BNF by a set of production definitions. The syntax to define a'production is: 
Synopsyslnc, . -u* 
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product ion_najne : product! on_l 1st; 
production jname - The product ion_nam€ is the reference name of the production definition. 
productionjist - The productionjist is made up of one or more production Jitems, 

10.2,1 Production Items 

One or more production items makes up a production list. Production items are made of terminals and 
non-terminals. 

A terminal is an indivisible code element It needs no further definition beyond the code block associ- 
ated with it Code blocks should be encapsulated in braces ({ }). A non-terminal is an intermediate vari- 
able defined in terms of other terminals and non-terminals. 

If a production item is defined using non-terminals, those non-terminals must then be defined in terms 
of other non-terminals and terminals using the production definition construct Ultimately, cvejy non- ^ 
terminal has to be broken down into its base terminal elements. 

Multiple production items specified in a production list can be separated by white space or by the OR 
operator (I). Production items separated by white space indicate that the items are streamed together in 
sequence. Production items separated by the I operator force a random choice, which is made every time 
the production is called. 

This is a simple example illustrating the use of production items: 

main : top middle bottom; 
top : one | two; 
middle : three | four; 
bottom : five; 

The main production definition is defined in tcmfis of three non-terminals: top^ middle^ and bottom. 
When the call is made to this random sequence, top^ middle^ and bottom are evaluated, and their defini- 
tions are streamed together. 

The top^ middle^ and bottom production definitions are defined in terms of terminals. The I operator 
forces a choice to be made between the one and two terminals and also between the three and four ter- 
minals. 

This sequence block leads to these possible outcomes: 

one tJiree five 

one four five * 

two three five 

two four five 

This is an example of a full set of production definitions: * . , , : . : 
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assemblyjrogram: text_section data„section ; 
text_section: {printf ( " .texf ) ; } iny_code ; 
data_section: {printf (" .data') ;} data ; 
data: initial ized_data | uninitialized.data 
iny„code: { /* Vera code */} 
initialized.data: { /* Vera code */ } 
xininitialized^data: { /* Vera code */} 



This example defines the production assembly^rogram in terms of text_section and data^section. The 
production textjsection is then broken down to include the string "text" and the non-terminal myjcode. 
The production data^section is defined in terms of cither of the two terminals inltialtzed_data and 
uninitializedjdata, the selection of which occurs when the randseq block is called. The resulting ou^ut 



is: 



.text 

iny_code output 
,data 

initial ized_data output OR uninitialized^data output 



The myjcode^ initializedjdatay and unmitializedjdata outputs are determined by the code blocks asso- 
ciated with those productions. 



10.2.2 Weights 

Weights can be assigned to production items to change the probability that tiiey are selected when thc^ 
randseq block is called. The syntax to declare a weight is: 

production_j:iame : weight production_item: 

weight - The weight must be in tiie form of Sc{expression) where the expression can be any valid Vera 
expression that returns a non-negative integer. Function calls can be made within the expression, 
but the expression must return a numeric value, or else a simulation error is generated. 

Assigning weights to a production item affects the probability that it is selected when the randseq block 
is called Weight should only be assigned when a selection is forced with the I operator. The weight fctr 
each production item is evaluated when its production definition is executed. This allows you to change 
the weights dynamically throughout a sequence of calls to the same production. 

This is an example of a weighted production definition: 

integer_ins true t ion : tO) add^ins true t ion 

I &(i*2) 6ub_instruction ; 

Hiis example defines the production integerjnstruction in terms of die weighted production items 
cddjnstrucdon and subjnstmction. If i is 1 when the definition is executed, tiiere is a 60% (3/5) 
chance tiiat addjnstruction is selected, and a 40% (2/5) chance tiiat subjnstruction is selected, 

Synopsyslnc. . - 
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10.3 Production Controls 

Vera provides several mechanisms that can be used to control productions: if-else statements, case 
statements, and repeat loops. 

10.3.1 If-eise Statements 

A production can be conditionally referenced using an if-else statement The syntax to declare an if-else 
statement within a production definition is: 

production_name : <if {condition) production^name else production_name> 7 
condition - The condition can be any valid Vera expression. 

If the conditional evaluates to true, the first production item is selected. If it evaluates to false, the sec- 
ond production item is selected, TTie else statement can be omitted. If it is omitted, a false evaluation ig- 
nores the entire if statement 

This is an example of a production definition that uses an if-else statement: 

ass€mbly_block : <if (nestingl/evel > 10) seci_block else anyJblock>; 

This example defines the production assemblyjbiock. If the variable nestingLevel is greater than 10, the 
production item seqjblock is selected. If nestingLevel is less than or equal to 10, anyjblock is selected, 

10.3.2 Case Statements 

A general selection mechanism is provided by the case statement The syntax to declare a case state- 
ment within a production definition is: 

production_name : <ca«e (prijnary_ejq3ression) 
casel^Bxpression ; production^name 
<:ase2^ejqpression : productiozj^name 

caseN^GXpression : production^name 
default: : product ion_name > ; 

expression - The expressions can be any valid V^a expression or comma-separated list of expressions. 

The primaryjtxpression is evaluated when the production definition is executed. The value of the 
primary_jexpression is successively checked against each case_expression. When an exact match is 
found, the production item corresponding to the matching case is executed, and control is then passed 
to the first line of code after the case block. If other matches exist they are not executed. If no match is 
• found, the default statement is executed. If no default statement is specified and no matches are fdUnd, 
control passes to the first line of code after the case statement without any production being executed. 

This is an example of a production definition using a case statement 
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asseinbly_block : <case(i*3) 
0 : seq_block 
3 : loop_block 
default : aiiy_block> ; 

This example defines the production assemblyjblock with a case statement The primary expression /^^3 
is evaluated, and a check is made against the case expressions. The corresponding production item is 
executed. 

10.3.3 Repeat Loops 

The repeat loop is used to loop over a production a specified number of times, Hie syntax to declare a 
repeat loop within a production definition is: 

prodxxction_jiame : <repeat {expression) production_naiae> ; 

expression - The expression can be any valid Vera expression that evaluates to a non-negative integer, 
including functions that return a numeric value. 

The expression is evaluated when the production definition is executed. The value specifies how many 
times the corresponding production item is executed. 

This is an example of a production definition using a repeat loop: 

seq„block : <repeat < random () ) integer_instruction>; 

This example defines the production seqJblocK which repeals the production item integerjnstruction a 
random number of times, depending on the value returned by the randomQ system function. 

10.3.4 Break and Continue 

Vera provides the break and continue statements for use inside randseq blocks. 



10.3.4.1 Break - ^^l - r> i - 

The break statement is used to terminate a randseq block. The syntax to declare a break statement iis: 

break; 

A break statement can be executed firom a code block within a production definition. When a brealc 
statement is executed, the randseq block terminates immediately and control is passed to the first line of 

'* - ^ 

code after the randseq block. 

This is an example of a production definition using a break statement: * 

SETaP_COUNTER: { 

integer regis = regFile.getRegisterO ; 

integer value .ADDI;,,._^-.»p,T,n ^ . - - r. - r.v* - - ' v.- 

nestingLevel++; 
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if (nestingLevel == MAX_NESTING) break; 

} ; 

This example executes the break if the conditional is satisfied. When tiie break is executed, control 
passes to the first line of code after the randseq block. 

10.3.4.2 Continue 

The continue statement is used to interrupt the execution of the cuzrent production. The execution con- 
tinues on the next item in the production from which the call is made. The syntax to declare a continue 
statement is: 

continue; 

The continue statement passes control to the next production item in the production from which the call 
is made without executing any code in between. 

This is an example of a production definition using a continue statement: 

LOOP_BLOCK: SETUP_CODNTER GEN^LABEL; 

SETUP_COUNTER: { 

integer regis = regFile.getRegister ( ) ; 
integer value = ADDI; 
nes tinglievel++ ; 

if (nestingLevel == MAX_NESTING) continue; 

} ; 

This example first executes the SETUP JCOUNTER production definition. When the continue is execut- 
ed, the code after the continue is ignored and control passes to the GEN_LABEL production definition. 



10.4 Value Passing 

Value passing within randseq blocks allows you to associate a data type with each production definition 
in order to pass values between production definitions. There arc two components of value passing 
within randseq blocks: value declaration and value passing functions, 

10.4.1 Value Declaration 

To associate a data type and value^with a given non-terminal production, you must declare the produc- 
tion using the prod declaration. The syntax to declare a production for value passing is: 

prod data^type production_jiame; 
daiajype - The datajtype integer, bit, string, enumerated Qrpe, or any object ' 
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producHonjname - The productionjiame is the name of the production that is passing the value. 

Multiple productions can be declared in a single declaration statement, similar to variables. Vera per- 
forms strict type checking for passing values. 

V 

10A2 Value Passing Functions 

Vera provides two functions used to pass values in randseq blocks: prodsetQ and prodgetQ. The prod- 
setQ and prodgetQ system functions can be called from Vera code blocks within production definition s. 

prodsetQ 

The prodsetQ system task is used to set a value associated with a non-terminal. The syntax to set a val- 
ue is: 

prodset (value [, productionjname I, occurrence^numberl ]); 

value - Tlie value is the value you want to pass. It must be of the same type as the prod declaration. It 
can be an integer, bit, string, enumerated type, or object 

production^name - The producHonjname optionally specifies the name of the non-terminal production 
the value is being assigned to. If it is omitted, the production that the task is called in is assumed to 
be the production to the left of the colon (:), 

occurrencejnumber - The occurrence^number optionally specifies which occurrence of the same 
production name receives the value. If the same production is referred to multiple times in the samie 
definition, the first is 1, and the others are numbered sequentially. If it is omitted, it is assumed to 
bel. 

The prodsetQ system task assigns the specified value to the specified occurrence of the non-terminal 
production. This value can be retrieved using the prodgctQ system function. 



prodgetQ 

The prodgetQ system function is used to retrieve values assigned to non-tenninal productions. The syia- 
tax to pass a value is: * 

prodget- ( {product ioxx_name I , occurrence_23umber] ] ) ; 

productionjiame - Tbe productionjname specifies the name of the non-tenmnal production the value 
has been assigned to. If it is omitted, the production that the task is called in is assumed to be tiic 
production to the left of the colon (:). 

occurrencejnumber - The occurrencejnumber optionally specifies which occurrence of the same 

production name receives the value. If the same production is referred to multiple times in the same 
definition, the firet is 1, and the others are numbered sequentially. If it is omitted, it is assumed to 
be 1. 

The prodgetQ system function returns the value assigned to the spedfied non-terminal production. 
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Production values can only be associated with production names to the left of the code block where 
prodsetQ is called. If you assign a value to the production name to the left of the colon (:), the value is 
passed up to the calling production, where it can be retrieved. 

Calling prodgetO on a production entry that has not been assigned returns an undefined value. 
You cannot set a value for a production that has not yet been executed. For example: 

main : prod_a {prodset (5 ,prod^b, 1) ; } procLb /* invalid! */ 

main : prod_a {prodset(prod_a, 2) ; } prod^b prod_a /* invalid! */ 
main : prod_a {integer trap = prodget (prod_a) ; 

prodset (tmp+5,prod_a) ; } prod_b /* valid! */ 

This is an example of how to pass values within a randseq block: 

program GenList 
{ 

list vsgList; 
randseq 0 
{ 

prod list_node ELEMENT; 

TOP : { vsgList = new; } LIST END 
; 

LIST : &(10) LIST ELEMENT 
{ 

list_node Inode = prodget ( ELEMENT, 1 ) ; 

vsgList . insert ( Inode ); 

printf ('last insert %Od\n*^ Inode, da ta ) ; 

} 

I ELEMENT 
{ 

list^ode Inode = prodget ( ELEMENT, 1 ); . 
,vsgList - insert ( Inode ) ; 
printf ('inserting %0d \n* , Inode. da ta ) ; 

> 

ELEMENT : { 

list_jiode Inode = new; 
prodset ( Inode ) ; 

printf ("new node is created %Od\n', Inode. data); 

} 

END : { vsgList.printAllO ; } - 
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This example defines the list object vsgList. When the randseq block is entered, the TOP production is 
executed. First, a list object is instantiated. Then the LIST production is executed. The LIST production 
consists of a weighted LIST ELEMENT production and an ELEMENT production. If the LIST EL]> 
MENT production is selected, the LIST production is called recursively and the ELEMENT production 
is postponed. The original selection between ELEMENT and LIST ELEMENT is then made again. The 
cycle continues until the ELEMENT production is selected. At that time, Inode is assigned a value via 
the prodset call in the ELEMENT production. That value is inserted into vsgList via the insert call in 
the code block. Finally, the previously unexecuted ELEMENT calls that had been postponed when 
LIST ELEMENT was selected are executed. Control is then passed back to the TOP production, which 
executes the END production. 

Note that each production is not assigned a single value. Instead, a stack of values can be assigned to a 
production, which are retrieved, in order, through the dynamic execution of the production set 
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Examples: Vera Stream Generator 

This is an example using the Vera stream generator. The example includes tiiese features: 

• Random sequence blocks 

• Productions 

• Value passing 

This example includes these files: 

• globaldefM 

• memCtUfmh 

• RUN (a run script) 

The RUN script generates a header file for vsg.m 

Files included in the distribution but not shown here include: 

• coveragcvrh 

• stimgen,vrg 



giobaidef.h 

tifndef FILE^GLOBALDEF_H 
#cLefine FILE_GLOBALDEF_H 

enum MEiCSEG = MEM_SEGO, MEM_SEG1, KE11^SEG2; 

enum COVERAGE_VAL_OPT = GENERIC_C0V, STATE_COV, TRANS_COV; 

♦define W_K00P 1 
♦define W.FMSH^CACHE 2 
♦define W_BtmST_READ 8 
♦define W_SINGI*E.READ 4 
♦define W_BDRST_WRITE 7 
♦define W_SINGLE_WRITE 3 

♦endif 
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memCtUf.vrh 

#ifndef INC_MEMCTL„IF„VRH 

#define INC„MEMCTL_IF_VPH 

# define INPUT„EDGE PS AMPLE 

#define OUTPUT_EDGE PHOLD 

#define OUTPOT^SKEW #1 

interface memCtl 
{ 

input [3:0] mc_state INPUT_EDGE ; 

inout 12:0] cmd INPUT_EDGE O0TP0T_EDGE OUTPUT_SKEW ; 
inout cache_hit INPOT„EDGE OUTPUT_EDGE OUTPinLSKEW ; 
inout cache_dirty INPUT.EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
input elk CLOCK ; 
} // end of interface inemCtl 

port mport 
{ 

mc^state; 
cmd; 

cache_hit ; 
cache_dir ty ; 
}//end it^jort 

bind mport mbind 
{ 

mc_s ta te memCt 1 . mc_s ta te ; 
cmd memCtl.cmd; 
caciie_hi t memCtI , cache_hi t ; 
cache_dir ty memC 1 1 , cache_dir ty ; 
}//end bind- 

#endif - 



vsg.vr 

i inc lude <vera_de fines . vrh> 
♦include •RTL/xnemCtl . vh* 
# include -memCtLif -vrh* 
i include • globaldef .h* 
# inc lude " s t imgen • vrh • 
fine lude •cover age. vrh* 
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extern t_MemCtl_Cov MemCtl^Cov; //coverage obj 

extern t_CmdPacket CmdPacket; //command packet object 

extern event evt_new_cmd; //global event variable, signalling new 



// task generate_test : 

// uses randseqO as a sequence generator to create 

// randomized sequence of commands out of the 6 command 

// NOOP, FL0SH_CACHE, BURST_READ, BURST_WRITE, SIKGLE^READ, 

// SINGLE_WRITE. Environment conditions such as xaemory addresses 

// and cache-hit status are generated dxxring the sequence also, 

// The productions are designed such that it will keep 

// generating commands until coverage-goal is met by 

// doing a query (GOAL) after each command 

task genera te„t est with it5>ort () 
{ 

integer f _cnt ; 

randseq ( ) 

{ 

prod integer FLUSH_A_LINE; 
STREAM : TRANSACTION 

<if ( !MemCtl_Cov. query (GOAL )) STREAM > 
TRANSACTION : GEN_ADDR SEL.CMD 
{ 

trigger ( ONEJLAST, evt„new_cmd } ; 

} 

GEN_ADDR : 
{ 

randcase 
{ 



//commcuid is generated 



1 : CmdPacket , gen_addr ( MEWLSEGO ) ; 
1.: CmdPacket. gen^addr ( MEK..SEG1 ); 
1 : CmdPacket, gen_addr { MEMLSEG2 ); 



) 



} 



SEL_CMD 



: t ( W_NOOP ) DOJIOOP 

( W„FLXJSH_CACHE ) {f_cnt = 0? } DO_FLUSH_CACHE 



& 



( W„BURST_READ ) DO_BURST_READ 
( W_SINGLE_READ ) DO_SINGLE_READ 
( WLBORST.WRXTE > DO_BURST_WRITE 
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DO_NOOP : 
{ 

CmdPacket , exec_cmd with (get_bind ( ) ) 
{ NO_OP ) ; 

} 

DO_FLUSH_CACHE : FI,USH_A„LINE 

< if ( prodget ( FLUSH_A_LINE ) < 31 } DO„FIiUSH.CACHE > 

# 

FLUSH_A_LINE : 
{ 

CmdPacket. exec_cmd with ( get_bind() ) 
( FLUSH^CACHE }; 
CmdPacket . incre_addr ( ) ; 
prodset ( f_cnt++ ) ; 

} 

7 

DO_BURST.READ : 
{ 

integer wait_time; 

CmdPacket . exec_cmd with ( get_bind{) ) 
( BURST^READ ) ; 

if ( CmdPacket, St im„cache_hit ) 

wait_time = 4 ; 
else if ( CmdPacket. stim_cache_dirty } 

wait_tirae = 6 ; 
else 

wait„time = 5; 
repeat ( wait^time ) e (posedge CLOCK) ; 

} 

DO_SINGLE_READ : 

{ 

integer wait^time; 

CmdPacket. exec_cmd with { get_bind() ) 

( SINGLE_READ ); 

if ( CmdPacket. stiitucache_hit ) 

wait_time = 1 ; 
else if ( CmdPacket. St iin_cache_dirty ) 

wait_time = 3 ; 
else 

wait_time - 2; 
repeat ( .wait_time } e (posedge CLOCK) ; 

} ^" - ' ■■-^ • ' ■ 
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DO_BURST„WRITE : 
{ 

integer wait_time; 

CmdPacket , exec_cmd with { getJbindO ) 

( BURST^WRITE ) ; 

if ( CmdPacket. St iitucache_hit ) 

wait_time ~ ^ ; 
else if ( CmdPacket. stinucache_dirty } 

wait_time = 6 ; 
else 

wait_time = 5 ; 
repeat ( wait_time ) © (posedge CLOCK) ; 

} 
# 

DO_SINGLE„WRITE : 
{ 

integer wait_tiine; 

CmdPacket . exec_cmd with ( get_bind{) ) 
( SINGLE_WRITE ) ; 
if ( CmdPacket .stiin_cache_hit ) 

wait^time = 1 ; 
else if { CmdPacket. St im„cache_dirty ) 

wait„time = 3 ; 
else 

wait„time = 2 ; 
repeat ( wait_time } e (posedge CLOCK) ; 

} 

}//end randseq 
}//end task 

RUN 

#!/bin/csh -f 

rm -f *,vro core *.vshell >fic /dev/null 
vera -cn^ -g -h vsg.vr 
if ($status) exit 1 
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11. Functional Coverage 

This chapter introduces Vefa's functional coverage analysis and discusses how it is used. It in- 
cludes these sections: 

• Coverage Overview 

• Coverage Definitions . ; . 

• Instantiation and Triggering 

• Coverage Feedback: The Query Function 

• Coverage Admiixistration 

• Cross Coverage 

• Backward Compatibility 

11.1 Coverage Overview < ' 

As chip designs grow more complex and testing environments become increasingly sophisti- 
cated, emphasis is placed not only on testing the chip but testing it completely. With hundredls 
of possible states in a system and thousands of possible transitions, the completeness of tests 
needs to be a primairy focus of any verification tooL 

Traditional coverage models use a code coverage methodology, Hiey check tiiat specific lines 
of code are executed at some point in the simulation. This method has inherent flaws. For in- 
stance, you can be certain that a device entered states 1, 2 and 3, but you cannot be certain that 
the device transitioned from state 1 to 2 to 3 in sequence. Even such a simple example displays 
the limitations of code coverage. WiQi a sophisticated chip, such coverage is not adequate to 
ensure the integrity of the design. 

Vera supports a functional coverage system- This system is able.to moiutor all states and state 
transitions, as well as changes to variables. By setting up a number of monitor bins that cone- 
spond to states, transitions, and variable changes. Vera is able to tack the activity in flie sim- 
ulation. 

Each time a user-spedfied activity occurs, a counter associated with the bin is incremented. If 
you establish'a bin for each state, state transition, and variable change that you want to moni- 
tor, you can check tiie bin counter after the simulation to see how many activities occurred- 
Thus, it is simple to check the degree of completeness of tiie tesfcench and simulation. 
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Vera further expands this basic functionaUty to include two analysis mechanisms: open-loop 
analysis and closed-loop analysis. Open-loop analysis monitors the bins during ti\e simulation 
and writes a report at the end stimmarizing the results. Qosed-Ioop analysis monitors the bins 
during the simulation and checks for areas of sparse coverage. This information is then used 
to drive subsequent test generation to ensure satisfactory coverage levels. 

11.2 Coverage Definitions 

To check the coverage for a given simulation, you create coverage definitions. For each cover- 
age definition, you must define the monitor bins, initialization routines, and any triggers or 
other synchronization mechanisms you want to use. Meanwhile, Vera assigns pre-defined 
properties and methods to the coverage objects that take care of the data coUection and much 
of the analysis. In this way. Vera successfully encapsulates a large portion of the code into re- 
usable objects, which greatly facilitates their use. 

Coverage definitions behave veiy similarly to classes that exist within the object-oriented 
methodology. like classes, coverage inslcOiC^have definitions. However, unlike a class defi- 
nition, coverage definitions cannot contain methods and variables. Instead, they contain c/ec/a- 
r^/onS of monitor bins. * - v . r ^ . f 

. Because coverage definitions behave very similar to classes within the object oriented method- 
ology, they can be used in a similar manner. For instance, if you have four copies of-the same 
bus protocol, you can instantiate four instances of the same coverage, definition- without creat- 
ing four separate coverage definitions. When you caU the coverage object,within a Vera task, it 
inherits the virhial port to which the task is bound. So the same coverage definition can be 
used to check multiple ports or signals, ' 

The basic syntax for defining a coverage definition is: 

coverago_dof Object^name {state^var labia, argximents) { 

coverage declarations; 
measure of coverage; 

coverage goal; ^ - , 

' . coverage option; . " - . . - ^ .vT 

initialization;'* ' ^' ^ . vi.^ -.-Tf i..^-. 

} 

state_vanable - The state joariable is the type and variable name being monitored by the 
coverage definition. It can be of the following types: integer, bit field (in the form 
bit[nl,-01), enimierated type, and port , . . 

The state variable can be used as a parameter throughout the coverage definition. 
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arguments - The arguments are mitialization parameters passed at instantiation. They have the 
same conventions as subroutine arguments and can have their default values set within 
the declaration. Arguments must be of the following types: integer, bit field, enumerated 
type and port variable. 

The details of the remainder of the coverage definition are explained in subsequent sections . 



Note - The coverage definition is just a definition. It does not 
instantiate a coverage object. To instantiate a coverage object, see 
Section 113, ^Instantiation and Triggering." 



11. Z1 Expressions within Coverage Definitions 

Expressions within coverage definitions are used for specifying coverage declarations, mea- 
sure of coverages, and coverage goals. These expressions are a subset of the general Vera ex- 
pressions. Expressions must be one of the following data types: integer, bit, enum, port_var or 
interface signaLThey cannot include arrays, the ~, ++, or - operator, or function calls other 
than queryO/ gct.cycleO, and get_timeO- Function calls are only allowed in if expressions and 
coveragejaalue expressions. Expressions wiflun coverage objects can reference global variables 
and arguments passed into the coverage definition. 

11 .2-2 Coverage Declarations 

Coverage declarations are used to declare legal states, illegal states, legal transitions, and ille- 
gal transitions. They associate biijs with these activities and monitor how many times tiiese ac- 
tivities occur within a simulation. 

11;2.2.1 State Declarations 

The syntax for a state declaration is: 

state stAte_bin_name {state_specification) conditional: 

state Specification 

In a state declaratioiv a single state or multiple states are associated, with a monitor bin via a 
state specification. The state spedfication is a list of elements (separated by commas) that are 
matched against the current value of the state variable. For the current cyde^ any matches in- 
crement the bin coimter by one. 

Each element of the state specification must be in one of the following forinats: 

1. expression - A coimter is added to the bin when the state variable matchesi 

the expression exactiy. 'x' or 'z' must matdi exacfly. 
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2. lowihigh - A counter is added to the bin when the state variable matches 

any value in the range from low to high. 

3. low:high:step:repeat - This creates multiple ranges. The first block ranges from low to 

high. The second block ranges from (high-^stq)) to (Z'^high- 
low-k-stq)). New blocks are generated repeat times. For example: 
2:5:10:3 would produce states {2, 3, 4, 5, 15, 16, 17, 18,28,29,30,311 
(2,3,4,5) -> (15,16,17,18) -> (28,29,30,31) 

Complex state specifications can be generated by separating multiple formats with commas. 
For example: 

state staLte_hin_name (8 'bOOOO_01XX, 8:10, 15:17:7:2) 

This State specification will increment the bin coimter if any of the specifications matches the 
state variable. In this example, a coimter will be added to the bin if: 

(i) the state variable matches ST^OOOCOIXX exacfly 

(ii) the state variable falls in the range of 8 to 10 

(iii) the state variable falls in the range of 15 to 17 or 24 to 27 



Note - 'x' and 'z' are not allowed in repeated range statements. 



A special case of a state declaration uses the all state specification- 
state state_bin_name (all) ; 

This statement indicates that all values of the state variable increment the specified bin 
counter. 



Note - If you use state(all), a significant amoimt of memory is used if 
the number of sampled and unique states is large. 

It is important to note that state specifications are evaluated only once, at the time the cover- 
age object is instantiated. While the state variable is being monitored, the state specification re- 
mains constant 

State Bin Names 

Bins can be assigned explicit names, or the Vera compiler can generate implicit names. The 
Vera compiler generates implicit bin names based on the state spedfication. The general for- 
mat is always prefaced by s_. The following characters are converted to underscores (_): com- 
ma C)/ colon (:), slash (/), dash (-), plus (+), asterisk (*), and period (.). The following 
characters are ignored when the bin name is generated: double quote (*), brackets ((]), paren- 
theses ( 0 )/ dollar sign ($), caret {^), backslash (\), and braces ({}), For example: 

,^n<»pfj^ inc. 
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state expression 

(5.7.9A1) 
(15:37) 
(base*10+3) 
(aU) 



implicit bin name 

s.5.7_9_ll 

s„15_37 

s_baseJ0_3 

s_aU 



Conditionals 

You can add conditional statements at the end of any state declaration. Conditional statement 
can be any valid Vera conditional statement. Fimctioiw other than get_cycle0 and get.timeO 
cannot be called in the conditional If there is a conditional statement attached to the state dec- 
laration, the bin coimter will be incremented only if both the condition is true and ihe state 
variable matches the state specification at the same time. For example: 

state jmp_ins (8 'bOOOO_01XX, 8:10, 15:17:7:2) if {test == ON) ; 

This state declaration creates the bin jirp_ins . The bin coimter is incremented when the 
state variable matches the specification AND the conditioruil is true. 

Multiple State Bin Declarations 

A state declaration can have multiple bins declared on a single line as follows: 

state bO (0), bl (1), b2 (2); 
In this example, bO, bl, and b2 are separate states, each with its own state specification. 

Further, multiple state declarations are allowed, and the same state can be associated with 
multiple bins. For example: 

state bO <0:10) ; 
state bl (10:20); 

In fliis example, state 10 is associated with both bin bO and bin bl. 
m_state 

The m.state state declaration is used to declare multiple state birts up to a meodmum of 40S>6 
bir\s. The syntax is: 

a\_state s ta te_biji^ame ( expl : exp2 ) ; 

statejbinjnante - The statejnnjname is fl\e base name of the state bins being created, 

exp - The exps can be any valid coverage expression. You caimot call functions in the 
expressions. The expressions can include variables. 

When the m_state declaration is used, multiple state bins are created, covering all, the values 
in the range. The expressions are evaluated when the coverage object is instantiated,. For ex- 
ample: 
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m_state si (2:4); 
This example creates these bins with their respective state values; 

state bin name state value 

sl„0000 2 

sl.OOOl 3 

sl.0002 4 

If no bin name is specified, the same example yields these bin ncimes and values: 

state bin name state value 

s_0002 2 

s_0003 3 

s_0004 4 



11 .2.2.2 illegal State Declarations 

Illegal state declarations associate illegal states with a monitor bin. The syntax is: 
b&d_8t&te error_bin_name {state_speclfication) conditional; 

Illegal or bad states are those states in the design that, when entered, result in verification er- 
rors. 

The state specification can be any expression or combination of expressioiis as in the state dec- 
larations. However, it is often useful to define every state that is not in the state declarations 
as a bad state. To use that definition of bad states, you can use the not state specification: 

bad_«tate Grror_bin_name {not «t«to) ; 

This statement increments the specified bin counter every time the state vsuiable matches a 
value not defined in the state declarations. If you do not specify an error bin name, the implic- 
it name is s_not_state. 

If you want to specify multiple bad states, you can use tiie m„bad_state declaration. The syn- 
tax is: - V. , , , . - ' 

. m_bad„«tate error_bin^name {expliexp2); 

When the m_bad_state declaration is used, a bin for each value in the range is created. If no 
bin name is specified, the same naming conventions for m.state are us^d. 

11.2.2.3 Transition Declarations 

Transition declarations associate state transitions with monitor bins. The syntax for transition 
declarations is: - - 

tr«ji« trans^bin^name (state_tTansitions) conditional: 

— Jf-y 
SyifiSS^Inc. 
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State Transition 

State transitions are specified by declciring a sequence of transitions between states. The gener- 
al format is; 

trans trans^bin^name (state_set_l -> state_set^2 -> -> state^set^N) ; 

A state set it made up of one or more transition states. Transition states can be any of the fol- 
lowing: 

1. a state bin, specified in a state declaration 

Z any of the state spedfiecs available in a state declaration 

3. a Perl regular expression matching a state bin name, enclosed in double quotes 

If multiple transition states make up a single state set, they must be enclosed by brackets {[]) 
and separated by commas. For example: 

traxLS trans^bin^name ([jms^ins, brixor, • jii5>[0-9]+*3 -> [15:20:2:100]); 

This example defines a complex state transition. The specified bin counter is incremented 
when any of the following occurs: 

(i) the state variable changes from a state defined in the jins_ins state declaration to a state 
that falls in the repeated range defined by 115:20:2:100] 

(ii) the state variable changes from a value in the range from br to xor to a state that falls in the 
repeated range defined by [15:20:2:100] 

(iii) the state variable changes from a state defined in any state bin that begins with *jmp" and 
ends with at least one digit to a state that falls in the repeated range defined by [15:20:2:100 1 

A special case for transition states is the all state transition argument 

tr«xx« trans^blzi_name (all) ; 
The specified bin coimter is incremented on any state variable transitions. 



Note - If you use trans(all}, a significant amount of memory is tised if 
the number of sampled and uiuque transitions is large. ' ' • 



Transition Bin Names 

Bir\s can be assigned explicit names, or the Vera compiler can generate implicit names. The 
Vera compiler generates implicit bin names based on the state transition. The general format is 
always prefaced by t_. The following characters are converted to underscores (_)• comma (,), 
colon (:), slash (/), dash (-), plus (+), asterisk (*), and period (.), The following characters are 
ignored when the bin name is generated: double quote (^), brackets {[]), angled brackets {<:>), 
parenfixeses ( 0 )/ dollar sign ($), caret (^), backslash (\), and braces ({}). For example: 
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transition expression 
(5->7->9-> 11) 
(15:37 -> 2:5) 

([basenO, 9] -> "jmpIO-giH-") 
(aU) 



implicit bin name 

t_5_7_9_ll 

U5_37_2_5 

t_base_10_9_jmp0_9_ 

t.aU 



Conditional 

You can add conditional statements at the end of any transition declaration- Conditional state- 
ments can be any valid Vera conditional statement Fimctions other than get_cycleO and 
get_time() cannot be called in the conditional. If there is a conditional statement attached to 
the transition declaration^ the bin counter will be incremented only if both the condition is 
true and the state variable makes the specified transition at the Scime time. For example: 

trans jmp.ins (8:10 -> 15:17:7:2) if (test ON) ; 

This transition declaration creates the bin jirp^ins . The bin cotmter is incremented when 
the state variable makes the specified transition AND the conditional is true. If you specify a 
sequence of transitions, the conditional is only evaluated during final transition. 

Multiple Transition Bin Declarations 

A transition declaration can have multiple bins declared on a single line as follows: 
trans bO (0 -> 1), bl (1 2), b2 (2 -> 3); 

In this example, bO, bl, and b2 are separate transitions, each with its own transition specifica- 
tion. 

A special case of a transition declaration uses the all transition specification. 

trans trans^bln^name (all) ; 
This statement indicates that all transitions increment the specified bin coimter. 

ni_trans 

The m_trans transition declaration is used to declare multiple transition bins up to a maxi- 
mum of 4096 bir\s. The syntax is: 

ai_trans trans_hin^name {expliexp2 -> exp3:exp4)7 

transjbitt^name - The transjbin_natne is the base name of the transition bins being created. 

exp - The exps can be any valid coverage expression. You cannot call functions in the 
expressions. The expressions can include variables. 

When the m_trans declaration is used, multiple transition bins are created, covering all the 
transitions in the specified ranges. Each set of expressions specifies a range. A bin is created 
for each permutation of valid states. For example: 

Synops^1lhc«, 
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m_trans tl (2:3 -> 4:5); 
This example creates these bins with their respective transitions: 



transition bin name transition 

tl_O0O0_O000 2 to 4 

tl_0000_0001 2 to 5 

tl_0001_0000 3 to 4 

tl.OOOl.OOOl 3 to 5 



In tiiis example, states 2 and 3 are given the identifiers 0000 and 0001, and states 4 and 5 are 
given the identifiers 0000 and 0001, These identifiers are used in the transition bin's implicit 
name. If other states are added to either side of the transition^ fliey are assigned identifiers in 
sequential order (i-e., the next state is 0002, and so on). 

If no bin name is specified, the same example yields these bin names and values: 



transition bin name transition 

tjomjmo 2 to 4 

t.OOOO^OOOl 2 to 5 

t_0001.0000 3 to 4 

t^OOOl^OOOl 3 to 5 



11.2.2.4 niegal Transition Declarations 

Illegal transition declaratioris associate an iliegcd transition with a monitor bin. The syntax is:: 

bad^trans trans^bin^name {state_^trajisitions) conditional; 

The state transition can be any state transition set valid for transition declarations. However, it 
is often useful to monitor ail transitions that have not been defined as legal transitions. For 
such instances. Vera uses the not trans argument 

bA<l_t:ran« trans^bin^jname {not tmx#} ; 

The coxmter associated with the specified bin will be incremented every time a transition oc- 
curs that is not explicitly defined in the transition declaration. If you do not specify the bin 
name, tiie implicit name is t_not^tratis. 

The not trans modifier applies only to single transitior\s between two state sets. It does not aj> 
ply to sequences of transitions. So, if you use not trans and you specify a sequence of transi- 
tions (A -> B -> C), you must also specify each valid trar\sition within the sequence (A -> B, B 
->Q. 

If you want to specify multiple bad trai\sitiorxs, you can use the m3ad_trans declaration- The 
syntax is: 

aOMiO^rmns €rrx>rJbii;_jtMUHe {expliexp2 -> exp3xexp4)i 
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When the m_bad_trans declaration is used, a bin for each transition is created. If no bin name 
is specified, the same naming conventioris for m_trans are used. 

1 1 .2.2.5 Coverage Declaration Example 

state S^IDLE ( IDLE ), s_FLUSH_C( FLUSH.C ), s_LOAD_C ( LOAD.C ); 
state s_B_RD ( B_RD0:B_RD3 ), S„B„WR ( B_WR0:B_WR3 ); 

state s_all_RD ( S_RD, B_RD0:B_RD3 ), s_all_WR ( S_WR, B_WR0:B„WR3 ); 
bad.state ( not state ) ; 

trans t_Noop ( IDLE -> IDLE ) if ( inbind,$cmd =-= N0_0P) ; 

trans t.CacheMissDirty ( IDLE -> •s„FLUSH_C* -> LOAD.C -> START ) 
if ( inbind.$cmd l== NO_OP iribind.$cind l== FLUSH_CACHE 
&& inbind.$cache_hit === 0 inbind. $cache_dirty === 1 ); 

trans t_SingleRead (START S„RD) if (inbind. $cmd === SINGLE.READ ); 

trans t_SingleWrite (START S_WR) if (inbind- $cmd === SINGLE_WRITE) ; 

trans t_BurstWrite( START -> B_WRO -> B_WR1 -> B_WR2 -> B_WR3) 
if (iabind,$cmd === BURST.WRITE) ; 

This ex£imple is a small piece of a complete coverage declaration. This example declares many 
valid states under various bin names. It also declares several valid transitions. Each time one 
of the defined activities occurs, the coxmter to the corresponding monitor bin is incremented 
by one. 

1 1 .2.3 Measure of Coverage 

The measure of coverage defines how coverage is specified. The default setting for the mea- 
sure of coverage computes the percentage of morutor bins that have a non-zero count The 
measure of coverage is recomputed each time qucry(GOAL) is called or each time a coverage 
report is generated. 

You can explicitly define the measure of coverage. The syntax is: 

coverago_val = 10 0* query (coinmahd, bizi^type, *l?in_pattera*; operand^ hit) 
/ query (coamiMd, binltype, ^hijxj>attem') ; 

command - Command determines the type of results you are going to query. It can be either 
NUM„BIN or SUM. Use NUM_BIN to coimt the nxmiber of selected bins. Use SUM to 
calculate the sum of coimter values on the selected bins. 

bin.type - The binjh/pe specifies the bin types you want to select from. The bin types are 
STATE, TRANS, BAD.STATE, and B ADJTRANS, To select more than one type of bin, 
tise the 'or' operator ( I ). • 

bin_pattcm - The bin^ttem variable is matched against the bin names of the specified type. 
Only those bins whose names contain the hin^ttem are included in the query. For 
example, if bm_paUem is Ijus", all bins with 1>us* in their names will be included. K you 
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want to select all bins whose names begin with a specific string, insert a caret {^) before 
the string (e.g. "'^bus")- To select all bins of the specified type regardless of name, use 
as the bin^attem. 

operand - The operand mxist be one of the following: greater than (GT), greater titan or equal to 
(GE), less than (LT), less than or equal to (LE), equal to (EQ), or not equal to (ME). 

hit - The hit specifies the number of coimter hits to which the query is compared using the 
operand. It can be any non-negative integer. 

The measure of coverage calculates your current coverage. Put simply, it is a ratio of the num- 
ber of states that have been ''hit" to flie total number of valid states. 

Using these definitions, you can explicitly define ti\e measure of coverage. For example, to de- 
termine the percentage of STATE and TRANS bins with at least one coimter hit, use: 

coverage_val = 100 * query (NDM_BIN, TRANS | STATE, GT* 0) / 

query (NOM_BIN, TRANS | STATE, *•*'); 

This example is the default measure of coverage. 

1 1 .2.4 Coverage Goal 

The syntax to set the coverage goal is: . , 

covcrage_goAl = expression: 

expression - The expression can be any valid coverage block expression. 

The coverage goal is a percentage between 0 and 100. If there is no explicitly defined goal, tlie 
default is 90. The coverage goal should be set such that when it is reached, all coverage obj<;c- 
tives have been met 

The coverage goal is most often used with the quexyO system function, discussed in 
Section 11.4, 

11.2.5 Coverage Options ^ — 

The syntax to set the coverage option is: 
cov«r&ge_opt:loxi = optloh; - 

option - The options are HI, which specifies that this object will be used for cross-correlation 
and needs a time stamp, LO, which specifies that only counter information must be 
retained, or CROSS^TRANS, which includes transition events in a cross coverage report 

- ... 

Multiple options can be selected using a + or I to separate options. The default setting is LO. 
If both HI and LO arc chosen, the option is HI. Because the CROSS.TRANS option is used 
for cross correlation, it can only be used with tiie HI coverage option. 
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The CROSS^TRANS modifier includes transition events in a cross coverage report. By de- 
fault, cross coverage reports include only state information. If the CROSS^TRANS modifier is 
active, the cross coverage report contains both state and transition information. In this way, 
you can include information on transitions that occur when specified states are in use. Howev- 
er, transition/ transition assodatioris are not included in the cross coverage report. 



Note - If CROSS JTRANS is active, it must be active for every 
coverage block in the coverage report If it is not, a warning message is 
issued and the cross coverage report is not generated. 



11.2.6 Initialization 

Coverage defirutions are initialized by an embedded case block that is invoked only when the 
definition is instantiated. The outer level of the case block resembles a standard Vera case 
statement except that it can also include fl\e full range of coverage statements. The initializa- 
tion case block can contain any of these elements: 

• coverage declarations (state, bad state, transition, and bad transition 
declarations) 

• measure of coverage 

• coverage goal 

• other case blocks 

The syntax for an iiutialization sequence generally follows this format: 

c&se {jinlti&liza.tion^aramater) 
{ 

expression! : statementl; 
express ion2 : sta tement2 ; 

default: 

} 

Initialization sequences are generally used to conditionalize coverage statements so that the 
coverage definition is more specialized upon instantiation. For example, an initialization se- 
quence can be particularly useful when passing flags as arguments when the coverage defiru- 
tion is instantiated. For instance, if statc_flag is defined such that false turns on bad states and 
true turns off bad states, the following syntax would be used: 

cas« (state_flag) ^ ^ 
{ 

0; bad_state bad^st_bin (0, 2, 3); 
def ault: 

'} - - • " • . • , - 
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This example declares states 0, 2, and 3 as bad states if the flag is set Each time this coverage 
definition is instantiated, the flag will be checked. This enables you to define one coverage 
definition, but use it in different ways throughout the simulation. 

1 1 .3 Instantiation and Triggering 

Coverage definitions are not created until they are instantiated using the newcov command. 
The syntax to instantiate a coverage definition is: 

coverage^definitioa izistance^name = aewGov(state_var, trigger, opt_args) ; 

coverage.def inition - Coveragejiefmtion is simply the name of the coverage defixution that 
you are instantiating, 

instance.name - The instancejname is the name of this instance of the coverage defirution. 
Remember that newcovQ can be used to create multiple instances of the same defirution. 

sfatejoar - The state joar is the value that is monitored by tixe coverage definition. It is the 
state variable or expression for which the coverage definition has been created. 

trigger - The trigger is a trigger expression that allows you to control when 

the object takes a sample. Coverage objects can be triggered on clock edges, variable 
changes, and sync events. 

optjargs - The opt_args are the optional arguments. They must correspond to the coverage 
definition's optional arguments, if any exist. 

The trigger can be used to sample on dock edges as per the synchronization command (see 
Section 4.4.1, "Synchronization''), When the specified clock edge occurs, the object is triggertid. 

The trigger can also be used to take samples only on changes to variables using the 
wait_var construct see Section 6.1.1.2, *wait_varO*)- When a variable change occurs, the object 
is triggered. 

Coverage objects can also be triggered on sync events (see Section 6.2.2, ^Sync''). When the 
sync is tmblocked the object is triggered. 

There are a few things to note when using triggers. Hrst, to elimix\ate race problems, if tiie 
trigger involves dock delays, the coverage object is invoked at the end of the simulation cyde 
after all Vera processing that can change variables is complete. Second, if the sample occtirs on 
every change, the coverage object is triggered at most once per simulation cyde even if tht! 
state variable changes multiple times. 

program iaemCtl__Test 
{ 

t_CmdPacket CmdPacket; 
t_MeiaCtl_Cov MejrCtl_Cov; 
t_CitM3LCov QoftdLCov; 
event evt.new_cmd; 
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// instantiates global objs 
res ethnic with mbind (); 
fork 

{state.snooper with mbindO;} 
{cmd„snooper { ) ; } 
join none 

// Test with GEKERIC_COV value 
CmdPacket = new; 

CmdPacket . command = NO_OP; // just to initialize before coverage begins 
MemCtl„Cov=newcov(inbind,$mc_state,©(posedge CLOCK) ,HI, 100, 
GENERIC_COV ) ; 

Cmd_Cov=newcov( CmdPacket -command, sync ( ALL, evt_new_cmd ) }; 
printf {■##### GENERATE SEQUENCE FOR GENERIC COVERAGE #####\n\n«); 
generate_test with mbind ( ) ; 

coverage ( CROSS, MemCtl_Cov, Cmd_Cov, • generic • rpt • ); 
}//end program 

task reset_mc with it^ort ( ) { 
$cmd = NO_OP async; 

@2 $mc„state == IDLE; }//end reset_mc 

task state_snooper with mport () 
{ 

string s_str; 
while (1) 
{ 

©(posedge CLOCK); 
case ( $mc_state ) 
{ 

4'dO : s_str = •IDLE"; 
4'dl : s_str - "START*; 
4' 62 : s_str = "FLUSH^C ; , . 
default : s_str = •UNKNOWN_STATE* ; 
}//end case 

if ( $mc_state === 4'dO, ) printf CVn*); 
printf (• %s -> s_str) ; 
}//end while 
}//end task state^snooper 

task cmd_snooper { ) 
{ 

string c_str; 
while (1) 
{ 

sync (ALL, evt_n€w_cmd ) ; 



... . ^. 
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case ( CmdPacket . command ) 
{ 

3 'do : c_str = •NO„OP-; 
3'dl : c_str = •BURST^READ' ; 
3'd2 : c„str = -BURST.VJRITE' ; 
3'd3 : c.fitr = •SINGLE_READ* ; 

default: error ("Unknown Command %Od\n* , CmdPacket • command) ; 

} 

printf (• ## CMD : %s ## c„str ); 
delay ( 2 ); 
}//end while 
}//end cmd_snooper; 

This example forks off two processes^ each of which calls one of the user-defined tasks. The 
cmd„snooper ( ) task calls a sync, which triggers one of the coverage objects. The other cov- 
erage object is triggered on the positive dock edge. 



1 1 .4 Coverage Feedback: The Query Function 

There are a set of related, pre-defined methods associated with coverage objects that allow you 
to review the current coverage status. These are all integer functions with the name query. 
The query functions are in these forms: 

query ( command) ; 

Query (camaiand, bin^type) ; 

query (command, Jbin_type, bli2_j>attem) ; 

query (command, bin^type, bin^attem, operand, hit); 

command - The basic form of query allows you to specify one of several commands: 

NUM.BIN, SUM, HRST, NEXT, GOAL and NAME Each command returns a different 
value based on the binjtype. < 

Cgptmfln^ Fyntfi?" 

NUM.BIN , , Counts the number of bins of type binjype 

SUM Sums the counters for aU bins of type Vtnjype 

FIRST Returns tiie coimt of the first bin of type hinjype (or -1 itor 

failure) 

NEXT Returns the count of the next bin of type binjh/pe in the 

sequence started with FIRST (or -1 if the sequence is com- 
plete) 

GOAL Returns a 1 if the coverage goal has been met (0 otherwise) 



Note - NEXT and GOAL can be tised oiUy in the single^argument 
fomu . 
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The single-argument form of the command applies to all bins. The additional arguments 
can be added to narrow the bin selection- 

hinjtype - The binjype is any of the vaUd bin types: STATE, BAD_STATE, TRANS and 
B AD_TRANS, Multiple bin types can be specified using the 'or' operator ( I ). 

bin^attem - The hin_pattem variable is matched against tiie bin names of the specified type. 
It can be any regular Perl expression. Only those bins whose names contain the bin_pattem 
are included in the query. For example, if bin_pattem is "bus", all bins with "bus" in their 
names will be included. If you want to select all bins whose names begin with a specific 
string, insert a caret (^) before the string (e.g. ^'^bus"). To select all bins of the spedfied 
type regardless of name, use as the bin_pattem. 

operand - The operand must be one of the following: greater than (GT), greater than or equal to 
(GE), less than (LT), less than or equal to (LE), equal to (EQ), or not equal to (NE). 

hit - Hit specifies the number of counter hits to which the query is compared using the 
operand. It can be any non-negative integer. 

So, to compute the sum of the bin counts for state or transition bins with counts greater than 
10 each, we would have: 

<Iu«ry{SUM, STATE I TRANS, GT, 10); 

To continue a process imtil at least 10 bins has 10 or more hits, use: 

while (mycovobj. query (SUM, STATE|TRANS, GT, 10) < 11) 

(...) 

You can also set up loops that continue processes imtil the coverage goal is met: 

while ( !mycovobj . query (GOAL) ) 
{...} 

It is £l1so possible to query the name of a monitor bin. The syntax is: 

Query_«tr (HAKE) ; ^ 

This function returns the monitor bin name in the FIRST/NEXT series (or null if tiiie series is 
complete). 

Note - Outside of a coverage declaration we need to qualify query to 
get the appropriate method. For example, to get the query method for 
tiie cpO coverage object, we would use cpO . query. 



11 .5 Coverage Administration 

These coverage tasks provide administrative control of coverage objects. The general format is: 
coverage (conanand £, ohject_listl t # *fi-ien^e*3 ) ; 
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command - The comimnds are: 



Command 


Function 


ON 


Turns coverage on (enables bin updating) 


OFF 


Turns coverage off (disables bin updating) 


CLEAR 


Qears all monitor bin counters 


SAVE 


Writes the bin data to the specified file 


LOAD 


Reads the bin data from the specified file 


REPORT 


Generates a coverage report 


CROSS 


Generates a cross-correlation report 



object Jist - The object Jist lists the coverage objects to be included in the execution of the 
command. If it is not included/ all coverage objects will be included, 

filename - The filename specifies where the cross coverage report is saved. It is also xised to 
specify the read and write files for the SAVE and LOAD commands. 

These commands allow you genend control of coverage objects. They also allow you to do m- 
elemental coverage of your tests. At the begiiming of a new test, you can LOAD the current 
coverage state, run the test to update the state, and then SAVE that state back to a file - to be 
updated again by a later test 



Note - You generally want to keep coverage turned off tmtil after the 
circuit has been reset. 



The REPORT option generates a coverage report, detailing each bin and the nximber of hits it 
has taken. The CROSS report does a cross correlation between objects. Remember that the 
coverage option has to be set to HI for each selected coverage object to be correlated. 

When using SAVE/LOAD, coverage objects must be loaded in the same order as they werei 
saved. In the TOADING* program, coverage definitions must also be instantiated in the 
same order as they were in the ^SAVING" program. 

This is an example call for a coverage report 

coverage (REPORT, memCtl_cov, •memCtl • rpt • ) ; 
This is the resultant coverage report 

Coverage Instance Name: HemCtl^Cov 
Coverage Instance Handle: 3 

Coverage Definition Name: t_MemCtl_Cov . . 

Coverage Goal: 1 

Coverages Option: 1 • - 

Measure of Coverage: 1 

Coverage Sait?)le Expression: f 
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state Naiue 


# defined values 


# hits 




S_START 


1 




125 


S_B_RDO 


1 




52 


S_B_RD1 


1 




52 


SJBJKD2 


1 




51 


s B RD3 


1 




52 


S-B_WRO 


1 




35 


E B WRl 


1 




35 


S_B_WR2 


1 




35 


s_B_WR3 


1 




35 


s_not_state 


0 




0 


Transition Name 


# defined 


transitions 





t_s_0_s_l 


1 


59 


t_s_0^s_3 


1 


31 


t.s_3_s_l 


1 


66 


t„s_2_s_3 


1 


35 


t_s_0_s_2 


1 


610 


t_s_2_s_0 


1 


575 


t„s_10_s_ll 


1 


35 


t„s_ll_s_12 


1 


35 


t_not_trans 


0 


0 



11.6 Cross Coverage 

Cross coverage refers to the timestainping of events to ensure that specified events happen si- 
multaneously. For instance, a transition from state 1 to state 2 may not be sufficient for testing 
the device. You may need to know that a transition from state 1 to state 2 occurred while an- 
other state was active. 
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To use cross coverage, you must set the coverage option to HI, You can also optionally set th<s 
coverage option to CROSS„TRANS if you want to include transition information in a cross 
coverage report 

To invoke a cross coverage report, you must invoke the coverageO system function with the 
CROSS command: 

coverage (CROSS , object_^listt * filename" ) ; 
This is an example of a program using cross coverage: 

♦define OOTPUT_EDGE PRO 
tdefine OUTPUT^SKEW #1 
#define INPUT.EDGE PSAMPLE 

# include < vera_def ines . vrh> 

# inc lude ■ counter .if* vrh " 

coverage_def cc_bitVec3 (bit [2:0] bitVec, integer cov_opt ) 
{ 

/* 

8 states: s_0, . , ,s_7 

7 trans : t_s_0_s_l , . . . , t_s_6_s_7 and t_s_0_7_s_0 

1 bad_state : s_no testate 

1 bad_traiis : s_not_trans 

default coverage_val, coverage_goal 

coverage_option = cov_opt 

*/ 

state (0), (1), (2), (3), (4), (5), (6), (7); 

trans t_s_0_s_l (0 1), t_s„l_s_2 (1 -> 2), t„s_2_s_3 (2 -> 3), 

t_s_3_s_4 (3 -> 4), t_s_4_s_5 (4 -> 5), 

t„s.5_s_6 (5 -> 6), t.fi_6_s_7 (6 -> 7) j 
trans t„s_0_7_£_0 (0:7 -> 0); 
bad_state ( not state ) ; 
bad^trans t_not_trans ( not trans ) ; 

coverage_option = cov_opt; 
}//end ccJbitVec3 defn 

program counter_test 

{ // start of top block 

cc„bitVec3 cc_cnth, cc„cntb2; 

string rptFileCrossSame - ■crossCcSame.rpt* ? 

// Start of co\mter_test 
reset^counter ( ) ; 

// start the high coverage , and clear their values 

cc_cath=ne«co V ( counter . count , 6 ( counter , coimt async ) , HI+CROSS_TRANS ]| ; 
cc„cnth2=newcov (counter .count, 6 (counter- coxmt async) , JKr+^gOSSjTRAKJS) ; 
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repeat (2) @(posedge CLOCK); 

coverage < CLEAR, cc_cnth, cc_cnth2 ) ; 

coverage ( CLEAR, cc_cnth2) ; 

repeat (2) ©(posedge CLOCK); 

// OFF and ON with obj-list to be no arguments 

drive_cotanter { 4 ); // all cov-co;mters up by 4 
drive_counter ( 5 ) ; 

// CROSS coverage report of the 2 virtually similar test 

coverage ( CROSS, cc_cnth, cc_cnth2, rptPileCrossSame ); 
} // end of program counter_test 

task reset_coimter () 
{ 

eo counter . start = 0; 
counter, stop = 1; 
62 coxinter * coimt == 0; 
}//end reset_counter 

task drive_stop { integer num_times ) 
{ 

repeat ( num^times ) 
{ 

€1 counter -Stop = 1; 
@2 counter - count == 0 ; 

} 

} //end drivers top 

task drive^counter ( integer niim_times ) 
{ 

integer exp_count, i; 

printf ("Driving counter %0d times — \n", nxim^times) ; 

repeat ( num_times ) 

{ 

eO coxinter. count ~ 3'dO; 

exp_count = 0 ; 

ei counter. start =1; 

for ( i = 0; i < 8; i-^+ ) 

ei counter . count == exp_count++; 
eo counter, stop = 1; 
62 counter . count == 3 ' dO ; 
}//end repeat 
}//end drive„counter 
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This example creates a coverage definition that declares 8 legal states and 7 legal transitions. 
Then the main program instantiates two coverage objects. The counter is driven muJtipie times 
and the states and transitions are monitored by the coverage objects. The resulting coverage 
report is: 

cc_cnth cc_cntli2 # hits 



s_0 




9 


s_0 


t_s„0_7„s_0 


$ 


s^l 


s_l 


9 


s_l 




8 


S-2 


s_2 


9 


s_2 


t_s„l_s_2 


9 


s_3 


s_3 


9 


s_3 


t„s_2„s_3 


9 


s_4 


s_4 


9 


s_4 


t_s_3_s_4 


9 


6_5 


s_5 


9 


6_5 


t_s_4_s_5 


9 


■s_6 


s_6 


9 


s_6 




9 


s_7 


£-7 


9 


Bj3 


t_s_6_s_7 


9 


t s 0 7 E 0 


£J0 


9 






8 


t_s_l_s_2 




9 


t_s_2_fi_3 


fi^3 


9 


t„s_3_s_4 


C-4 


9 


t_S_4_6_5 


e^S 


9 




s„6 


9 




fi„7 


9 



Synopsyslnc. 




244 Chapter 11. Functional Coverage 



Vera 4.0 User's Manual 



Maximum Coverage Instajice bin combinations; 256 
Detected Coverage Instance bin combinations: 24 
Percentage combinations: 9-375 

This coverage report lists all of the states for each coverage object, and the number of times the 
other coverage object observed a state activity or transition activity during the state. 



11.7 Backward Compatibility 

Vera continues to support an earlier version of functional coverage that was not integrated 
into the object-oriented framework. In this implementation, you declare a coverage block for 
each state variable you wish to check. These coverage blocks are then automatically invoked 
each time the state variable changes. 

Coverage blocks need to be declared in the main program, either before the program keyword 
or immediately aften 

coverage_bloc)c name 
{ 

< vector declaration> 
<state declaration>* 
<transition declaration>* 
<coverage options> 

} 

The vector declaration is a list of Vera input or inout signals as specified in an interface state- 
ment. Sampling is done at the edge associated with the first signal. 

The state declarations associate a name with a numeric value, defining all of the legal states. 
The statements are of the form: 

«t*t« name number; 

The transition declarations come in two forms. Self-transitions are of the form: 

trangition najaeiname; 

which says we will allow a transition from name to name. More general transitions are speci- 
fied with: 

trancition source: destl, dest2, destS; 
which specifies transitions from source to any of the specified destinations. 

11.7.1 Coverage Options 

The coverage options for the earlier version of functional coverage are: 
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Coverage option Effect 

illegaLstate Reports when an illegal state is entered 

iliegaLtransition Reports when an illegal transition occurs 

illegal_self_transition Reports illegal self-transitions when enabled 

The default is for all self transitions to be legal. However, if it is not valid to stay in a state for 
more than one cycle, you can use this option. In this mode, you must specify tiie self-transi- 
tions that are valid. All other self ^transitions are reported as illegal 



1 1 .7.2 Coverage Reporting 

All of the coverage tasks that were outlined earlier (except CROSS) work with coverage 
blocks, A call to coverage(REFORT) produces a report that details the status for all tiie spe<d- 
fied legal and illegal transitions: 





VERA Coverage 


Report for fsm^check ****** 


<src> <dst> 


<niim> 


<last„cycle> 


IDLE 


PEKD 


5 


5428 


IDLE 


WRO 


22 


4543 


IDLE 


RDO 


24 


3854 


PEND 


IDLE 


0 





VERA COVERAGE ERROR: PEKD -> IDLE transition is not covered 

11.7.3 Conditional Coverage 

Sometimes it is necessary to have finer visibility into the state-machine behavior than just 
which states and transitions were taken. In this case, adding pseudo-states can often provi<ie 
the requisite refinement For example, we can cover state transitions driven by a control sigixal 
by creating two IDLE states: 

coverage f sitL.checK-i { 

vector fsm.cntl, fsm. state; 

state PEND 5'bxOOOl;// first bit does not affect state 
state IDI,E_Z 5'bOOOOO; 
state IDLE_0 5'blOOOO; 

trans IDLEJ, PEND;// transition while cntl==0 
trans IDLE_0, PEKD;// transition while cntl==l 

} 

We check for transitions from the IDLE to the PEND state, but now for botii possible valueis of 
the fsm,cntl signal. 
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Examples: Coverage Analysis 

This is an example tising functional coverage analysis. TTie example includes these features: 

• State and transition coverage 

• Coverage options 

• Coverage values 

• Coverage object triggering 

This example includes these files: 

• globaldefM 

• tnemCtl^.vrh 

• main,VT 

• coveragcvr 

• RUN (a nm script) 

The RUN script generates a header file for coveragcm. 

Files included in the distribution but not shown here include: 

• vsg.vrh 

• stimgen.vrg 



globaidef.h 

tifndef FILE_GLOBAIiDEF_H 
tdefine FILE_GLOBALDEF_H 

enum MEM^SEG = MEM.SEGO, MEM_SEG1, MEM_SEG2; 

enum COVERAGE_VAL_OPT = GENERIC^COV, STATE_C0V, TRANS_C0V; 

#define W_N00P 1 
fdefine W_FLUSH„CACHE 2 
♦define W.BURST_READ 8 
#define W_SINGLE_READ 4 
#define W_BURST_WRITE 7 
♦define W_SINGLE_WRITE 3 

#endif 
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memCtl.if.vrh 

tifndef INC_MEMCTL_IF_VRH 
#define INC„MEMCTL„IF_VRH 
#define INPUT.EDGE PSAMPLE 
tdefine OUTPUT_EDGE PHOLD 
Idefine OUTPUT_SKEW #1 

interface memCtl 
{ 

input [3:0] mc_state INPUT_EDGE ; 

inout [2:0] cmd INPUT.EDGE OUTPUT.EDGE OUTPOT.SKEW ; 
inout cache_]iit INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
inout cache_dirty INPUT„EDGE OUTPUT_EDGE OUTPUT_SKEW ; 
input elk CLOCK ; 
) // end of interface memCtl 

port ir^ort 
{ 

inc„s tate; 
cmd; 

cache_hit; 
cache_dirty; 
}//end mport 

bind mport icibind 
{ 

mc_state ineinCtl,inc_state; 
cmd memCtl.cmd; 
cache_hit memCtl . cache_hi t ; 
cache_dirty memCtl .cache_dirty ; 
}//end bind 

#endif 



main.vr 

# include < ver a_def ines . vrh> 

# inc lude • RTL/memCt 1 , vh • 
# include •memCtl*if .vrh' 

# inc lude • coverage . vrh " 

# inc lude • s t imgen , vrh ■ 

# inc lude • vsg , vrh • 

program coverage_exaii^le 
{ 

t_Cmd_Cov Cmd^Cov; 
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t_MemCtl_Cov MemCtl.Cov; 

t_CmdPacket CmdPacket? 

e ven t e vt„new„ciad ; 



// instantiate command packet 



CmdPacket = new; 

CmdPacket*coinraand = NO_OP; // just to initialize before coverage begins 



// instantiate coverage objs 



MemCtl^Cov = newcov (iribind,$mc_state,^(posedge CLOCK), HI, 



10 0 , GENERIC.COV) ; 
Cmd_Cov = newcov ( CmdPacket .command, sync ( ALL, evt_new_cmd ) ); 

printf (•########## GENERATE SEQUENCE FOR GENERIC COVERAGE 

##ft######\n\n-); 
genera testes t with mbind ( ) ; 

coverage ( CROSS, MemCtl„Cov, Cmd^Cov, " generic. rpt* }; 
} / /end program 



# include <vera_de fines . vrh> 
#include "RTL/memCtl ,vh* 

# inc Inde • memC 1 1 . if . vrh • 

# inc lude * s t imgen . vrh • 

extern t_CmdPacket CmdPacket; 

// Coverage Obj Type t_MemCtl_Cov 

// cover the command state-machine-values 

// and the transitions among them 

// single- transitions are listed to prevent bad_trans (not trans) 
// from catching transitions defined in multiple*trans bins - 
// but not covered individually 

// coveragejval is calculated by 3 types of coverage- levels controlled 
// by argument 4 

coverage^def t_MemCtl_Cov (bit [3:0] mc^state, integer cov_opt# 



coverage.vr 



integer cov_goal, COVERAGE_VAL_OPT cov_val_opt ) 



{ 



state E_IDLE ( IDLE s„FLUSH_C( FLUSH_C ), S_LOAD_C ( LOAD_C ), 
s_START ( START ) , s_B_RDO ( B_Rd6 ) , 6_B_RD1 ( B_RD1 ) , 
s_B_RD2 ( B_RD2 ) , s_B_RD3 ( B_RD3 ) , S_S JEUD ( S„KD ) . 
S_S_WR < S_WR S_BJWRO ( B_.WRO ) , c1b_Wr1 ( B_WR1 ), 
s_BJWR2 ( B_WR2 ), s_b1wR3 ( ^BIWR3 ); ' 
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state s„B_RD ( B_RD0:B_RD3 ), s_B_WR ( B„WR0:B_WR3 ); 

state s_all_RD { S„RD, B_RD0:B_RD3 ), s_all_WR ( S„WR, B„WR0:B_WR3 }; 
bad_state ( not state ) ; 

trans t_Noop < IDLE -> IDLE ) if { inbind,$cmd === NO_OP) , 
t_CacheHit ( •s.IDLE* -> "s.START' ) 

if ( inbind,$cmd !== NO„OP xribind.$cmd !== FLUSH_CACHE 

&& nibind.$cache_hit === 1 )r 
t_CacheMiss ( "sJDLE' -> LOAD_C -> "s_START* ) if ( inbind.$cind !== 

NO_OP && inbind.$cind !== FLUSH_CACHE && ihbind,$cache_hit === 0 

&£c inbind.$cache_dirty === 0 ), 
t_CacheMissDirty ( IDLE -> •sJFhaSHJC* -> LOAD_C -> START ) 

if ( inbind.$cmd !== NO_OP && inbind.$cind !=- FLUSH„CACHE 

&£c inbind,$cache_hit === 0 && mbind. $cache_dirty === 1 ). 
t_FlushCache ( IDLE -> FLUSH_C -> IDLE ) if ( inbind,$cmd === 

FLUSH_CACHE ) , 

t_B;arstRead { START -> B.RDO -> B_RDl -> B_RD2 -> B_RD3 ) 

if ( inbind.$cmd === BURST_READ ), 
t_SingleRead ( START -> S_RD ) if ( naDind,$cmd === SINGLE_READ ), 
t_SingleWrite ( START -> S_WR ) if ( inbind,$cind === SINGLE_WRITE ), 
t„B;irstWrite ( START -> B„WRO -> B_WR1 -> B_WR2 -> B_WR3 ) 

if ( inbind.$cmd === BURST_WRITE ); 

// All Valid Single Trans 

trans ( IDLE -> START ) , ( IDLE -> LOAD_C ) , ( LOAD_C -> START ) , 

( FLUSH_C -> LOAD_C ) , ( IDLE -> FLUSH_C ) , { FLUSH_C -> IDLE ) , 
( START -> B.RDO ) . ( B_RDO -> B_KD1 ) , ( B_RD1 -> B_RD2 ) , 
( B_RD2 -> B_RD3 ) , < B_RD3 -> IDLE ) , ( S_RD -> IDLE ) , 
( S_WR -> IDLE ) , ( START -> B_WRO ) . ( B_WRO -> B_WR1 ) . 
( B_WR1 -> E_WR2 ) , ( B_WR2 -> B_WR3 ) , ( B„WR3 -> IDLE ) ; 

bad_trans { not trans ) ; > .. .: 

coverage_option = cov_opt ; 
case '{ cov_val_opt ) 
{ 

GENERIC_COV : 

coverage_val = query { NUM_BIN, TRANS | STATE, , GT, 0 ) 

/ query ( NUM_BIW, TRANSlSTATE, •-*•); 
STATE_COV : cover age_val = query ( NUl^BIN, STATE, ".*•, GT, 2 ) 

/ query ( NUM„BIN, STATE, V*' ); 
TRANS_COV : ' • 

coverage.val = query ( NUIL.BIN, TRANS, •.**,GT, 2 ) 

/ query ( NUICBIN, TRANS, ); 
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}//end case 

coverage_goal = cov_goal / 100; // in fraction 
}//end t„MemCtl_Cov 

// Coverage Obj Type t^CmoLCov 

// covers the commands and some selected transitions between them 

coverage^def t_Cmd_Cov ( bit [2:0] cmd_yalue ) 
{ 

state S JSIO_OP ( NO_OP ) , S_BURST_READ ( BUKST_READ ) , 

S_SINGLE_READ ( SINGI/E_READ ) , S_BURST_WRITE ( BURSTJWRITE ) , 
S_SINGLE_WRITE ( SINGLE_WRITE ), s.FLUSH^CACHE < FLUSH^CACHE ); 

bad_state ( not state } ; 

trans back_to_back_burst_rd ( BX3RST_READ -> BURST_READ ) , 
back_to_back„burst_wr ( BURST_WRITE -> BURST_WRITE ), 
t„BURST_READ_BURST_WRITE ( BtJRST_READ -> BURST_WRITE ), 
t_BXXRST_WRITE_BURST_READ ( BURST_WRITE -> BURST_READ ) 
trans t_ALL„WRITE.ALL_READ ( CBURST_WRITE, • s_SINGI*E_WRITE " ] 
-> I •sJURST^READ", SINGLE_READ] ); 

coverage_option = HI; //needed to do cross coverage 
}//end t_Cmd_Cov 



RUN 

#!/bin/csh -f 

rm -f *,vro core *.vshell >& /dev/null 
vera -cn?> -g -h coverage, vr 
if ($status) exit 1 
vera -cn^ -g main.vr 
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12. 



Multiple Module Support 



This chapter introduces Vera's mxiltiple module support It describes the different components 
of multiple module support and details how they are vised. This chapter includes these sec- 
tions: 

• Introduction 

• Overview 

• Project FUes 

• Configuration Files 

• Generating a Project-based Configuration 



Thus far, we have described how to create Vera testbenches as monolithic, single programs 
that are connected to the simulation through one of two methods: the test-top metiiod and the 
HDL node method. In addition to these methods. Vera supports a project-based configuration 
methodology that jillows you to create testbenches with multiple modules. 

Using the test-top mettiod, the Vera shell is iristantiated as a component in a test-top file that 
was either generated by the Vera template generator or created manually. This method has the 
advantage of keeping the Vera test-bendi source code independent of tiie actual connection to 
the simulation, which allows you to use the test-bench in multiple simulation environments 
without having to recompile the code. However, the test-top method forces you to have a test- 
top level on which all connections between ttie test-bench and simulation must be made. This 
limitation is sigiuficant when making connections deep in the hierarchy of the simulation 
structuie, ' 

The HDL node method uses constructs in the interface files to connect directly to the simuLi- 
tion environment without the need for a test-top file. This method allows you to easily malce 
connections between the test-bench and fiie simulation environment, even at points deep in 
the hierarchy of the simulation structure. However, using the HDL node method forces you to 
use test-bench source code that is dependent on the connection to the simulation. Thereforej, 
you must recompile the soiuce code each time ttie connection is changed. ' 



Note - Multiple modules are not yet supported for VHDL. • 



12.1 



Introduction 
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Vera's implementation of project-based configuration grants you the advantages of both earli- 
er alternatives without the limitations associated with each. Project-based configuration allows 
you to create test-benches that are independent of the actual connectior\s to the simulation en- 
vironment and connect those benches to any point in the simulation hierarchy without the 
need for a test-top configuration. 

Project-based configuration has the added advantage that Vera test-benches can be treated as 
modules that can be instantiated multiple times and run concurrently in a single simulation. 

The power offered through the project-based methodology is substantial even for users who 
prefer a monolithic approach, and it can be used without the multiple program capabilities. 

12.2 Overview 

This section gives a brief overview of the components of the project-based configuration ap- 
proach. 

Vera's multiple module support is based on its implementation of project-based methodology. 
There are three major components to this approach: 

1, An overall project (.proj) file specifying testbenches used in the simulation 
Z A configuration (.vcon) file for each testbench module 
3. The Vera object (,vro) files for each testbench module type 

Project Files 

The project file specifies which modules are used in the simulation. For each testbench module 
being used, the project file must have a corresponding section that specifies the module name, 
the configuration file, and the Vera object files associated with tiiat particular module. 

Configuration Files 

Each tes&ench module must have a corresponding configuration file! The configuration file 
specifies how the module is conr\ected to the simulation. It coimects Verilog signals to Vera in- 
terfaces. Configuration files also specify any docks that are needed, declare all Vera-Verilog 
task calls, and define dock generators with a specific period and timing. 

Note that the connections between the Verilog signals and the Vera interfaces can be changed 
in the configuration files without recompiling flie tesfeendi source code. 

Vera Object Files 

The Vera object files are binary files created when the source (.vr) files for the testbench mod- 
ules are compiled. A separate object file is required for each tes&ench. 



Vera 4.0 User's Manual 



Chapter 12, Multiple Module Support 255 



12.3 Project Files 

The project f Ue contains information for each testbench module being used in the simulation. 
Each module is listed, followed immediately by a list of the configuration file and object files 
associated with the module. The syntax for the project file is: 

tnain modulel^name 
modulel^naiae * vcon 
siodulel^objectl.vro 

moduIel.objectJRr. vro 



main moduleN^name 
moduJ eN^name . vcon 
moduleN^objectl . vro 

moduleN^objectN* vro 

Each module defiiution begins witii the main keyword and is followed by a modidejname. The 
modulejname is simply a unique instance name for the module. The definition line is followed 
by lines specifying the configuration file and all Vera object files associated with that modul<;. 

You can include a module jiameMxl file in place of the Vera object files. 

The project file can contsdn Vera pre-processor directives and macros such as #include and 
• #define. The normal Vera style comments (// and /* .„ */) are also supported in the project 
file. 



12.4 Configuration Files 

The configuration file contains the information specifying how the testi>ench module is con- 
nected to the simulation. Most importantly, it indicates how signals are connected between tlie 
testbench and DUX and it defines dock generators. 

The syntax for a configuration file is: 

tlma«cale timescale^steLtement 
clock clocK-Statement 
connect cormBCt^statement 
vtfrltajik veritask^Btatement 

Each of these statements is discussed in detail in subsequent sections. 

12,4,1 Timescale Statement 

The timescale statement sets the time between dock ticks. The syntax is; 
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timescale timescale^description 

timescale^description - The iimescalejiescription is in the form of a nprmal Verilog timescale. 

The timescale statement is optional. If you include a timescale statement in the configuration 
file, an equivalent Verilog 'timescale statement is generated in the Vera shell file. 



1 2-4.2 Clock Statement 

The clock statement creates a clock generator in the Vera shell file, which drives the specified 
Vera clock. The syntax is: 

clock clock_jiame period period^number offset initieil_value 

clock_name - The dockjname is the name of tiie Vera clock. It is specified as either 
SystemClock or inteTfacejnamexlockjnaTne. 

periodjnumber - The periodjiumber specifies the cycle length for the clock in nanoseconds, 

offset - The ojfset sets the delay before the clock changes for the first time. The default is 0. 

initialjpalue - The initial joalue is the value tfie dock starts at (either 0 or 1), The default is 0. 

The clock statement is optional. If a Vera clock does not have a dock statement and is not con- 
nected to any Verilog node through a connect statement, it will be listed in the I/O list as an 
input to the Vera shell module (except for SysternQock, which will never be listed as output in 
the I/O list). 

Finally if a Vera dock has a cormect statement, with or without a clock statement, it will not be 
listed in the I/O list of the Vera shell module. 

1 2,4.3 Clock.alias Statement 

The clock_alias statement aliases a Vera dock to another Vera dock. The syntax is: . 
clock.&li«.s ciocKjiaxael - clocKJxame2 

A dock cannot have a dock statement and be on the left-hand side of the dock„alias state- 
ment This is disallowed because it assigns two docks to the same dockname. Such assign- 
ments generate compilation errors. 

12A4 Connect Statement 

The connect statement cormects a Vera signal or dock to a specified Verilog node. The syntax 
is: 

connect direction vera^name verilog^name skew skew_value 

— - 
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direction * The direction can be one of the foUowingf in, input, out, output, or inout. The in or 
input direction specifies clocks and signals into Vera from the DUT. The out or output 
direction specifies clocks and signzds out from Vera into the DUT. The inout direction 
specifies bidirectional signals. The direction is checked against the direction specified in the 
interface. Mismatches result in compilation errors. If the direction is not specified, flie 
direction is taken from the Vera interface. The direction for Vera clocks is ignored. 

verajnatne - The verajmme is the name of the Vera signal you are connecting to the DUT. The 
format for the verajmme is interfacejname.signaljname, where the interface arid signal are 
specified in the interface specification. . . 

verilogjname - The verilogjname is the name of the Verilog signal to which fiie Vera signal is 
being coimected. It should include the Verilog hierarchal path. If the verilogjname is not 
specified, the Vera signal is not coimected directly to a Verilog node. Iristead, that signal is 
assumed to be connected through the I/O port list of the Vera shell module. This is useful 
if tiie Vera-shell is explicitly instantiated and cormected to the simulation tiirough the 
module ports. In this case, the port name used would be interfacejnamesignaljname. 

skew - The skew can be either iskew (input skew) or oskew (output skew). The default is no 
skew. 

skewjoalue -The sfxwjoalue is the length of tiie skew type specified. If you specify input skev/, 
the skewjodtte should be 0 or negative. If you specify output skew, the skewjoaltie should 
be 0 or positive. The default skewjoalue is 0. 

The connect statement is necessary to cormect the Vera tes&ench signals to the DUT. 

12.4.5 Veritask Statement 

The veritask statement maps a Vera task name to a Verilog task path in a Vera-Verilog task call. 
The syntax is: ^ ^ ^ 

verajtask^name - The v€ra_task_name is the name of the Vera task being mapped to Verilog. 

verilogjtask^name - Hie verUogJaskjname is the Verilog name of the Vera task. It should 
include the Verilog hierarchal path. 

This statement is optional If it is missing for a Vera-Verilog task call, a warning is printed and 
the default (the original path from the veritask statement in the Vera source code) is used. 



12.5 Generating a Project-based Configuration 

To generate a project-based configuration with multiple modules: 

1. Compile the source code for the individual testbendti modtiles. 

Tliis generates the Vera object files and Vshell files required to run the simulation with tfie 



258 Chapter 12. Multiple Module Support 



Vera 4.0 User's Manual 



testbenches. 

2. Create a configuration file for each tes&ench module. 

If the testbendi source files are available, you can generate a template configuration file by 
typing: 

vera -vcon program. "vr 

program - The program,vr contains the progrcim block for the module* 

You must then customize the template configuration file as necessary by specifying sig- 
nal cormections, clock periods, and any Verilog tasks that need to be defined in the con- 
figuration file. It is important that the signals are cormected to the correct Verilog nodes. 

3. Create an overall project file that contains information on all modules necessary for the simu- 
latiori. 

4. Create Vera shell files for each testbench module listed in the project file: 

vera -proj file. pro j 

This generates a Vera shell file called modulemmejshell.v for each module. This Vera 
shell file is used dxiring tiie Verilog compilation. The Vera shell file is generated from the 
Vshell (.vshell) file created when the tesfcench source code was compiled. 

5. Rim the simulation with the +vera_pload switch: 

verilog + vera j?load=proj_i2aine. proj inodl_shell . v ... modPJLshell . v 

The above flow eliminates the need for a test-top file that instantiates the Vera shell module. 
However, you can still use the test-top file approach with a project-based approach by deliber- 
ately not specifying cormections for Vera interface signals in the .vcon file. Unspecified inter- 
face signals result in a printed warning message during Vera shell creatiorv. The signals are 
automatically listed as I/O signals in the Vera shell module The Vera shell module must then 
be connected to the rest of the simulation by instantiation. 

Note - It is possible to mix the two approaches in a single project file 
where only some test-bench modules require instantiatioru 
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Example?: Multiple Modules 

This is an example of multiple module usage. This example includes these files; 

• SjfticMemMon^vr 

• SyncM€mMon.vcon 

• SyncMemTestvr 

• SyncMemTestvcon 

• multitnod.proj 

• RUN (a run script) 

Files included in the example distribution but not present here include: 

• jmblicjtasks.vr 

SyncMem.if.vrh 

interface SyncMein_if 
{ 

inout CE OUTPUT_EDGE OUTPUT_SKEW 1NPUT_EDGE; 
inout OE OOTPOT^EDGE OUTPUT_SKEW INPUT_EDGE; 
inout [7:0] AD OUTPOT_EDGE OOTPOT.SKEW INPOT_EDGE; 
inout [31:0] D INPUT_EDGE PRZ OUTPUT_SKEW; 
input elk CLOCK; 
} // end of interface SyncMem 

globals.vrh 

♦define ADDR^SIZE 8 
#define VATP^SIZZ .32 

SyncMemMon.vr 

♦define OOTPUT_EDGE PRZ 
♦define OUTPUT_SKEW #1 
♦define INPUT_EDGE PSAMPLE 

• include < vera^de f ines • vrh> 

• inc lude " publ ic_tas ks . vrh • 

• include 'SyncMem.if.vrh' 
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// This program serves as a monitor which runs indefinitely 

// and looks for bad signal values (X and Z) on the OE and CE pins 

// of the verilog SyncMem model. 

// At the same time, it will report any write/read activities to 
// the model by monitoring the CE and OE signal combinations 

program SyncMeitumonitor 
{ // start of top block 

// Start of SyncMeirL.test 

©(negedge SyncMem_if .CE) ; // wait till initial impedence is overriden 

// by test or other connections 

while (1) 
{ 

@ (po sedge SyncMem_if . elk) ; 

SyncMem_if ,0E = void; // void drive to synchronize 

fork 

{ 

if < SyncMem_if.CE === I'bl t& SyncMem„if .OE === I'bO ) 

rp tWr i t eMem ( ■ SyncMem_i f . AD ■ , SyncMem„i f , AD , " SyncMem^i f • D • , 

SyncMem_i f . D ) ; 
if ( SyncMem_if .OE === I'bl ) 
{ 

e (posedge SyncMem^if . elk) ; 

rp tReadMem ( " SyncMem^i f , AD " , SyncMem_if . AD , " SyncMem_i f , D * , 
SyncMem_i f . D ) ; 

} 

} 
{ 

if ( SyncMeiruif -OE === I'bx ) rptErrorSig ( ■SyncMem.if .OE' , 
I'bx ); 

if < SyncMeituif .OE =-= I'bz ) rptErrorSig ( "SyncMem^if .OE' , 
I'bz ); ' ' - 

} 
{ 

if ( SyncMem_if .CE === I'bx ) rptErrorSig ( •SyncMem^if .CE" , 
I'bx ); 

if ( SyncMen^if .CE ===== I'bz ) rptErrorSig ( •SyncMenL.if .CE* , 
I'bz ); 

} 

join all 

}//end while ' . 

) // end of program SyncMem^test ' - . , ^ 

Sympsysjnc.^^ 
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SyncMemMon.vcon 

clock SyncMem_if ,cik period 100 
connect inout SyncMein_if ,CE-SyncMem.CE 
connect inout SyncMem_if .OE=SyncMem.OE 
connect inout SyncMem_if .AD=SyncMein.AD 
connect inout SyncMem^if .D=SyncMeni.D 
connect output SyncMem^if .clk=SyncMem.clk 
// timescale lOOns/lOns 
clock SystemClock period 100 

SyncMemTest.vr 

#define OUTPUT_EDGE PHOLD 
tdefine OUTPUT_SKEW «1 
Idefine INPUT_EDGE PSAMPLE 

# include <vera_de fines . vrh> 
# include • global s.vrh' 
#include 'public^tasks .vrh' 
# include 'SyncMem, if . vrh* 

// This test will write to the verilog SyncMem model 
// data = (addr + 5) from addr 0 -> 255 
// Then it will read back the data and verify them in 
// reverse order of addresses. 

program SyncMem_test 
{ * 

integer i; 

// Start of SyncMem^test 

reset_mem(); . - 

printf (" setting data \n'); 

for ( i = 0; i < 256; i++ ) 
set_data ( i, i + 5 ) ; 

printf (■ getting data \n*); 

for ( i = 255; i >= 0; i— ) 
if (get_data(i) !== (i+5)| 

error ('inconsistent data in memory location %0d getting %0h, 
expecting %Oh\n* , i, get_data(i), i+5 ) ; 

printf (• all done \n«); 

exit (1); // to terminate simulation altogether 
}// end of program SyncMem^test 

Synopsysinc. I. 
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task reset_inein {) 
{ 

ei SyncMem^if .OE = 0; 
SyncMem_if ,CE = 0; 
SyncMenuif .AD = 8'bZ; 
SyncMein_if .D = 32 'bZ; 
ei SyncMem_if .D = 32 'bZ; 
}//end reset_niem 

task set.data ( bit [ADDR_SI2E-1: 0] wrAddr, bit [DATA_SIZE-1: 0) wrData ) 
{ 

€1 SyncMeia_if .OE = 0; 
@1 SyncMem_if .CE = 1; 
SyncMein„if ,AD = wrAddr; 
SyncMem_if ,D = wrData; 
ei SyncMem„if .OE = 0; 
SyncMem_if *CE = 0; 

ei SyncMem_if .0 void; //void expect 

} / / end s e t_da t a 

fvmction bit (DATA„SIZE-1 : 0] get_data ( bit CADDR_SI2E-1 : 0] rdAddr ) 
{ 

ei SyncMem„if ,OE - 1; 
SyncMein_if .AD = rdAddr; 
e (posedge CLOCK) ; ^ 
get_data = SyncMem_if ,D; 
61 SyncMem„if .OE = 0; //void drive 
}//end get_data 



SyncI\/lemTest.vcon 



clock SyncMenuif - elk period 100 
connect inout SyncMen^if .CE=SyncMem.CE 
connect inout SyncMen^i f * OE=SyncMem , OE 
connect inout SyncMenuif .AD=SyncMem.AD 
connect inout SyncMem^i f . D=SyncMem • D 
connect output SyncMem^if -clk=SyncMem.clk 
// timescale lOOns/lOns 
cloc> SystemClock period 100 
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13, Vera-CORE 

This chapter introduces Vera-Core and describes how it used. It includes these sections: 

• Introduction 

• Vera-CORE Usage Model For IP Vendors 

• Vera-CORE Usage Model for IP Users 



13.1 Introduction 

Developers of ASICs often look outside of their own firm for help in creating complex circuits;. 
They purchase syntiiesizable modules QP cores) from IP vendors, and integrate.the cores into 
their RTL descriptions. Using IP cores provides two very important advantages for the devell- 
opers: it shortens the development time, and it allows them to purchase debugged, robust 
modules. 

However; while offering distinct advantages, their is an element of risk in using IP cores. Be- 
cause developers are generaUy not as knowledgeable of others' work, latent bugs in the cores 
can lead to enormous losses of time. Additionally, bugs can be introduced to the ASIC desiga 
by improper cormection or use of tiie cores. 

Because these bugs can spell disastrous results for both the vendors and developers, both 

groups must strive to eliminate such problems. In doing so, the traditional approach has been 

to include monitors with the IP cores that catch problems and notify developers. The monitor 

are used to check for protocol violations by the system, to check for protocol violations by tlie 

core itself, to check for internal error states within the core, arid to accumulate coverage 

information at the core boundary and wittiin tiie core. 

Traditioi^y, these monitors have been «nbedded in the IP RTL usm^ 

the inherent flaws with Verilog in creating and maintainiiig complex monitors- have made su<ii 

solutiorw very limited and incomplete .-c : . ^ . 

While Verilog is generaUy inadequate for sudi tasks. Vera is a language expUdtiy designed for 
expressing these monitoring functions. Vera's multiple module support, flexible connection 
scheme, and project-based configuration capabiUties make Vera a superior tool for developmg 
such checking mechanisms. Moreover, Vera has the unique capabiUty to support Vera modules 
written by IP vendors withbut the need for regular Vera runtime ficenses. This means that de- 
velopers can run simulations using tiie IP cores (written in Vera) wittiout purchasing Vera H- 
censes by simply connecting ttie testbench signals to tiie hieraichal OUT signals where tiie 
Vera-CORE is to be stitched. • 
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A general flow diagram of Vera-CORE is shown in Figure 13-1. 



Synopsys 



IP User 




Figure 13-1 General Vera-CORE flow diagram 

13.2 Vera-CORE Usage Model For IP Vendors 

This section details how IP vendors use Vera to integrate monitors into their IP cores so that 
developers can use the cores in their simulation environment 

The steps to create the Vera-CORE file set are: 

1. Include monitors and coverage objects within the Vera source (.vr) files, 

Z Compile the Vera source files using the -ip switch This creates Vera binary files that can be 
. used without a Vera runtime license. . r . 

3, Create the configuration file: 
vera -vcon f^iename.^n: 

filename - The filename is the name of the IP core source file, 

4, Create the project file for the IP core induding the configuration and ob^ 

5, ' Create the Vera shell files: 

vera -proj filename, pro j 
filename - The filename is the name of the IP core project file 
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6, Distribute the resultant Vera shell files (shell. v), object fUes (.vro), configuratior\ files (.vcon), 
and project file (.proj). 

13.3 Vera-CORE Usage Model for IP Users 

This section details how IP users use Vera-CORE files without a Vera runtime license. 
To use Vera-CORE files: 

1, Download the Vera-CORE runtime libraiy from the Synopsys ftp site. 

2. Modify the existing configuration files to make direct signal cormections between the IP cora 
and tiie HDL design. Each testbench signal must be connected to the hierardial signal path 
where Vera-CORE is to be stitched. 

3. Create a Vera list file (.vrl) that includes the project (.proj) and module (shell.v) fHes. 

4, Rtm the Verilog simulation using this switch: 
+ver a_iaload= f iiename, vrl 
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Examples: Vera-CORE 

This is an example of Vera-CORE usage. This example includes these files: 

• counterAfvrh 

• counter jchecker.vrh 

• counter jJiecker.vr 

• counter jchedmjocon 

• counterjchecker.vrl 

• cornier johedcer.proj 

• counter j:overage.vrh 

• counter jooverage^vr 

To generate this Vera-CORE usage models you should: 

1. Generate the test-top file^ interface file, and Vera source file: 

vera -tert^ -t coxonter -c elk counter. v 

This creates the files counterAestJtop.v, counterAf.vrh, and counter.vrdmp, 
2- Edit the counter.if,vrh interface file to make the signal connections. 

3. Generate the configuration (.vcon) file: 
vera -vcon counter_checker . vr 

4. Edit the counter jchecker,vcon file to make the correct signal connections. 

5. Instantiate counterjchecker_sheIl inside the DUT. 

6. Use the RUN script 



counter.if.vrh 

#ifndef 1NC_C0UKTER_IF„VRH 
♦define INC_COUNTER„IF_VRH 

// Note: counter.if.vrh is edited so that all signals are inputs 

interface counter„checker 

{ 

input rst_n PSAMPIiE; 
input elk CLOCK; 
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input Qout PSAMPIiE; 

input [3:0] COUNT PSAMPLE verilog_node •counter . count_reg [3 : 0] 
} // end of interface counter 

#endif 



counter_checker.vrh 

tifndef INC_TMP_COUNTER„CHECKER_VRH 
#define INC_TMP.COUNTEIL_CHECKER_VRH 
#endif 



counter_checker.vr 

#define OUTPUT_EDGE PHOLD 
idefine OUTPUT_SKEW #1 
tdefine INPUT.EDGE PSAMPLE 

# include <vera_def ines , vrh> 
# include " counter. if .vrh" 

# include " counter_coverage . vrh • 

program Count er_Checker 
{ 

reg [3:0] count; 

counter_sm_cov cntO = 

newcov ( coiinter^checker . COUNT , © ( cotmter_checker . elk) ) ; 
while (1) 
{ 

i-f ( count er_checker . rs t_n == 1) 
{ 

print f ( ■ count er_checker . Qout==%b , 

iitycount=%d\n* ,counter_checker, Qout, count) ; 
if (count ~ 4'd9) 
{ 

©0 counter_checker . Qout =- 1; 
^(posedge counter_checker .elk) ; 
count = 0; 

> 

else 
{ 

eo counter_ciiecker . Qout == 0; 
e (posedge counter„checker , elk) ; 
count = co;int + 1; 

} 
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} 

else 
{ 

@ (posedge count er_checker . c Ik) ; 
count = 0 ; 

counter_checker.Qout == 0; 

} 

coverage (REPORT, cntO, •counter.FSM.rpt " ) ; 
} //end of while (1) 
} // end of program counter_test 



counter_checker.vcon 

//clock coxinter.clk period 100 

connect input counter_checker . rs t_n=counter_tb . Ul . rs t_n 
connect input count er_checker • clk=counter_tb • Ul , elk 
coimec t input counter_checker , Qout=:coxinter„tb , Ul . Qout 
// timescale lOOns/lOns 
clock SystemClock period 100 

counter_checker.vrl 

counter_checker . vro 
counter^coverage . vro 

counter_checker.proj 

main counter.checker 

coianter_checker • vcon 
counter_checker . vr 1 

counter_coverage.vrh 

fifndef INC_TOP„COUNTEIUCOVERAGE_VRH 
fdefine INC_TMP_CX)UNTER_COVERAGE_VRH 

enum count er_s tat es = SO, SI, S2, S3, S4, S5, S6, S7, S8, 59; 
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extern cover age_def counter_sin_cov 
( 

bit [3:0] comit_s tate 

); 

tendif 



counter^coverage.vr 

# include <vera_de fines . vrh> 
# inc lude * counter -if. vrh " 



enum count er_s tat es = 


SO 




4'hO, 


SI 




4'hl, 


S2 




4'h2, 


S3 




4'h3, 


S4 




4'h4, 


S5 




4'h5, 


S6 




4'h6, 


S7 




4'h7, 


SB 




4'h8, 


S9 




4'h9; 



coverage_def counter„sin__cov (bit [3:0] count_state) 
{ 

state sO(SO) ,sl(Sl) ,s2(S2) ,s3 (S3) ,s4 (S4) ,s5(S5) ,s6(S6) ,s7(S7} , 

s8(S8) ,s9(S9) ; 
bad_state (not state) ; 

trans reset (SO->SO) ; 
trans sO_sl (S0->S1) ; 
trans sl_s2 (S1->S2) ; 
trans s2_63 (S2->S3) ; 
trans s3„s4 (S3->S4) ; 
trans s4_s5 (S4->S5) ; 
trans c5„s6 (S5->S6) ; 
trans s6_s7 (S6->S7) ; 
trans s7_s€ (S7->S8) ; 
trans 68_s9 (S8->S9) ; 
trans s9_sO {S9->S0} ; 
bad_trans (not trans) ; 

coverage_option = HI; 

} 

- , r\ 
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RUN 

# ! /usr/bin/csh -f 

vera -cmp -ip -h -I. counter_coverage. vr 
vera -cmp -ip -I, coxinter_checker , vr 
Is *vro > coiznter_checker,vrl 

echo "main co\mter_checker* > coimter_checker .proj 
echo •counter„checker.vcon" » count er_checker.proj 
echo comter_checker,vrl » count er_checker. pro j 

vera -proj counter_checker.proj 
verilog +vera_pload=counter_checker .proj \ 
cotinter_checker_shell * v . /counter . v 
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14. Vera-to-HDLTask Calls 

Vera is an HDL co-simulation. Because of the close interaction between the two simulators in 
the verification process^ it is often useful to call tasks across platforms. For this reasbn, Veni 
enables you to call HDL tasks from within Vera and also provides a means to call Vera tasks 
within HDLs* This chapter discusses how to make these calls and includes these sections: 

• Calling HDL Tasks from Vera 

• Calling Vera Tasks from Verilog 

14.1 Calling HDL Tasks from Vera 

Vera allows you to call HDL tasks from Vera and transfer data back and forth between Vera 
and the HDL. To declare an HDL task in Vera, use the following syntax within your main pro- 
gram module: 

verilog_taa)c task^name {arguments) ■inst.patJa*; 
vhdl„taL«k ta.sk_name {arguments) ^inst_path^ s 

taskjname - The taskjname is the name of the HDL task you want to call. 

arguments - Task call arguments are passed from Vera to the HDL when the task is called. 
Arguments can be of the following types: integer and bit field. Note that you can pass 
strings as bits tising this construct hiil(8*stringjlengthyi:0] str, where string Jength is the 
number of characters in string str. 

tnst^ath - The inst_path is the instantiation path of the task in the HDL. It identifies the HDL 
task within the HDL hierarchy starting at the top level HDL module*^ ; ■ , 

This is an example of an HDL task call from within Vera: - -r.iu. : > ' 

verilog_task chip.init (bit [7:0] init_reg) • top . chip /chip_inif ; 

This example calls the Verilog task chip_init and passes the bit field variable initjreg. TTie 
task can be foimd within the top • chip hierarchy in the Verilog declaration. 

Because Vera identifies this declaration as a task definition, it must occur in ttie top code 
block. However, if you want to call the HDL task from other files, you can define it as an oc- 
temal task using tixe extern construct ' : 

extern verilog_task (arguments} ; 
extern vhdl^task {arguments) ; 

For example, to declare the chip_init task so it can be called from other files,"use: 
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extern verilog_task chip^init (bit [7:0] init_reg) ; 

14.1.1 HDL Tasks in Vera: Outputs/lnouts 

For HDL outputs and inouts. Vera reflects the output value if the Vera formal argument is pre- 
fixed by the var keyword. 

Note - It is important to define the var parameter in the HDL as inout. 



This is an example of the var cor\struct with HDL task calls: 

verilog_task get_status (var bit [7:0] status_word) •top.cpu. status ■ ; 

verilog„task chip_init (bit [7:03 init„reg) ; 

{ 

bit [7:0] word; 
integer i; 

chip.init (8'b0000_0000) ; // OK 
get_status (word) ; //OK 

get_status (i) ; // Error: formal is bit [7:0]; actual is integer 

get_status (8 'b0000_0000) ; //Error: formal is var; actual is constant 

} 

The task call of chip_init is successful because the Verilog task has been defined to accept 
any bit[7:0] as a parameter. The get.status (word) task call is successful because "word" 
matches the formal variable type specified in the dedaratioru The get_status (i) task call 
does not succeed because the variable type of the argument (integer) does not match the for- 
mal declaration (bit [7,-0]). The get_status (8 'b0000_0000) task call does not succeed because 
the argvunent passed is a constant and the formal declaration is a variable. 

14.1.2 Type Checking HDL Tasks in Vera 

Vera can check the argxmient types of HDL task declarations within Vera .and any task calls 
made within Vera, However, Vera cannot access the task definition made within the HDL. So 
Vera cannot check the argument types in the Vera program against the argument types in the 
HDL definition. Therefore, you must check that the declarations in Vera are consistent wifli 
the HDL task definition. 

If the types are not consistent, the results of the task calls are impredictable. Although the 
right type of implicit conversions may occur; this is not guaranteed. Instead, it is recommend- 
ed that you use types which are consistent in Vera and HDL, and do any type conversion sep- 
arately. 
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Note - This is equivalent to what happens when calling external 
hmctions in C, where the burden of consistency between the extern 
declarations and the libraries is not on the compiler but on the 
programmer (or on lint). 



1 4.2 Calling Vera Tasks from Verilog 

Vera provides mechanisms to call Vera tasks from ihe HDL Currently this is only available 
witii Verilog desigi\s, 

14.2.1 Declaring Vera Tasks for Export 

If you want to call Vera tasks from an HDL, the tasks must be declared with the export con - 
struct in the top level Vera file (the program file):, 

export task task^name (arguments) { 
task_contents ; 

} 

arguments - The arguments are passed from the HDL to Vera when the task is called. They can 
be of type integer or bit field. Strings can be passed as bits using this construct 
hii[i^*stringJmgthyVXS\ sir, where stringjength is the number of characters in string str. 
The arguments can be var and non-var variables as welL Default arguments can be 
specified. However, while they will apply to calls made from Vera code, they will not 
apply to calls made from the HDL* 

task_contents - The taskjcontents can be any Vera code valid in normal task definitions. 



Note - You can only export global tasks. You cannot export class 
methods or functions because of the restriction of function usage 
within an HDL, 



As an example, examine: 

export task foo( integer ntim) { 

printf(*Task foo{) called with num %Od!J\n', num ); 

} 

This example declares a task f oo and passes the argument num of type integer. 



14.2.2 Calling Exported Vera Tasks 

When you declare an export task, a task with the same name is generated in the vera_shell 
module. It is called from the HDL as vshell . taskuaame. For example: 
vshell.foo(S) ; 
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However, if the vera.shell exists as a co-top-level module (test-top connections between Vera 
and the HDL signals are done using "HDL^node" constructs in the interface), then the task 
must be called from the HDL as vera_shell . task^name. 

Exported tasks behave as normal Vera tasks and can be called within the Vera code. 

Vera imposes no restrictions on the contents of exported tasks. Exported tasks can have delays, 
forks/joins, and calls to other tasks or functioris including calls back to HDL tasks. 



Warning - Though Vera tasks are re-entrant. Vera task calls from an 
HDL are NOT re-entrant because of the Verilog task wrapper inside of 
the vera_shell. 



14.2,3 Exporting External Tasks 

Exported tasks must be declared in the program file. However, exported tasks can be external 
Vera task declarations. So the definition of the body of the task can be in a separate subroutine 
file, which is compiled and included separately. If this is the case, only the export extern dec- 
laration has to be in the program file, and only the following line needs to be in the program 
file: 

export extern task task_nainei€irgumGnts) ; 

The Vera task declaration and task definition can be in the same file. If they are both within a 
program file, you can export the task if either (or both) has the export prefix. 

In a subroutine file, task definitions cannot be of type export The compiler simply ignores the 
prefix in this case. Therefore, a task that is declared as an export extern in a program but 
whose body is defined in a separate subroutine file should not have an export prefix in the 
subroutine file. Whether or not a task is exported depends only on how it is declared (or de- 
fined) in the program file. 
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15. 



Calling C/C++ Functions 



This chapter discusses Vera's handling of C and C++ function calls. This chapter includes these sec- 
tions: 

• I>eclaration and Invocation 

• UDF Arguments 

• Linking UDFs to Vera 

• PLI Support Procedures 

• Handling Special Events 



Ali Vera UDFs (user-defined functions) must be declared before they are used, as cither tasks or funcj- 
tions. The syntax to declare a UDF is: 

function data_^type $udf^namo {arsruments) ; 
task $ udf_name ( argimen ts ) ; 

datatype - The datajtype specifies the data type returned by the function call. Functions can be of type 
integer, bit, and string. The default data type is integer, 

udfjftame - The udf^name is the name of the UDF being declared, 

arguments - Hie arguments can be arguments of type integer, bit and string, and they can include var 



15.1 



Declaration and Invocation 



declanoions. 



15.2 



UDF Arguments 



UDF arguments must be handled from the Vera side and the C/C++ side. 



15.2.1 Vera UDF Arguments 

The size and type of the UDF arguments in the function or task call must match exactly those in the 
declaration. If they do not, a compilation error occurs. 



For example, this task declaration and call result in a compilation error 



task $iny_task (integer i) ; 
$roy_task ( s tr ing_a ) ; 
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Vera also supports bidirectional arguments with UDFs using the var construct. Arguments passed using 
the var construct can both pass and receive data when the function or task is called. For example: 

task $iny_task (integer var bit [7:0] mydata); 

When using bidirectional arguments, you must be careful to type check the call with the declaration. 
For instance, given the above task declaration, this call results in a compilation eiror: 

$iny_task(100,200) ; 

This call results in an error because a constant is passed (200) where a variable is expected (mydata). 

You can specify an unknown number of arguments by using an asterisk (*) in place of actual arguments 
in the function or task call For example; 

task $iay_printf ( * ) ; 
If you use this construct, the arguments must be of type integer or bit 

15.2.2 C/C++ UDF Arguments 

Integers and strings are passed as is. They do not need a Vera data structure to be passed to Vera, 
The bit vector data structure that Vera uses is: 

typedef struct t_vecval 
{ 

int avalbits; 
int bvalbits; 
} s_vecval , *p_vecval 

The values that this data structure yields depend on the aval and bval integer values. Table 15-1 shows 
the values. 

Table 15-1 Bit vector data structure values 



aval bval Value 

0 0 0 

10 1 

0 12 

1 1 X 



The Vera Data data structure is used to transfer values between Vera and the UDF. The Vera Data data 
structiu'e is: 

typedef struct VERA_DATA 
{ 

int typG; 
union 

Synqps^sfnc* 
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{ 

int int^value; 
char string; 
struct 
{ 

int expr^ngroups; 
int expr_vec_size; 
S—vecval expr_value^; 
} bit_val; 
} data; 
} vera_data; 

type - The type must be VERA.INT.X, VERA.INT, VERA.BIT, or VERA.STRINQ depending on 
the value type being passed. The integer equivalents of these types are 1, 2, 3, and 4 respectively. 

int^value - The intj^alue is the integer value of any data being passed. 

string - The string is the string value of any data being passed. It can be NULL if the string on the Vera 
side is NULL, 

€xpr_ngroups - The exprjngroups is the number of groups in the expression value. 
€xpr_yec_size - The €xpr_vec_size is the number of bits in the expression value. 
€xpr_yalue _p - The expr_value_p is a pointer to the expression value. 

More information concerning this data structure can be found in the Verilog PU Reference Manual 

15.3 Linking UDFs to Vera 

To link UDFs to Vera, you must modify a UDF table in the verajusenc file and create object files, 

15.3.1 Vera UDF Table 

To link UDFs to Vera, you must put an entry into the Vera UDF Table for each user routine. The table 
SVERAJiOME/UbA^erajusenc. The syntax for a table entry is: 

v«r*_u«er_c*ll_«itry V«r*_OTr_T»ble [ ] = { 

type^ ^proc^name" , proc, misc^roc, data, * comment* 

} 

type • The type should be cither VERA_USER„TASK or VERA_USER_FUNC, . 

procjname • The proc_name is the name of the UDF being linked, as it is known to the user. 

proc - The proc is the actual UDF name, as it is called within Vera. It is called with the argument datcu 

misc ^roc - The misc^roc is called when Vera starts and when it transfers control back j^d forth witb 
the HDL, This procedure is discussed in Section 15.S, ''Handling Special Events,** 
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data - The argument data is passed to the UDF call. It must be an integer. 
comment - The comment can be any user comment. 

The Vera UDF Table is loaded dynamically at runtime from the library veraJiocaLdL 

15.3.2 Object Files and veraJocaLdI for Verilog 

The verajocaldl file is a dynamic library file that you must manually generate when you create your 
UDF object files. There arc two steps you must take to create the verajocaldl file: 

1 . Compile verajusenc and all your library files with the appropriate position independent code options to 
create the verajocaldl file. 

2. Link the verajocaldl file with the necessary object files and libraries. 
This process is platform-specific, 

HPUX 

To create the verajocaldl file with object files: 

CO -c +2 -I$VERA_HOME/lib c_files vera_user.c 

OR 

gcc -fpic -I$VERA_H0I1E/Iib affiles vera_user,c 

cjiles - The cjlles are the UDF files you are linking with Vera. 

After compiling verajusenc^ link the verajocaldl file with the necessary object files: 

Id -b +e syssci^rod.entry + ermo -o vera_local,dl o^files \ 
vera_user.o vera_kemel -Ic 

oJUes - The ojiles are the compiled UDF object files. 
Solaris 

To create the verajocaldl file with object files: 

cc -K pic -c -I$VERA_HOME/lib c^filGS vera_use'r,c 

OR 

gcc -fpic -c -I. -I$VERA_HOME/lib entiles vera^user.c 
cJUes - The cjiles arc the UDF files you are linking with Vera. 
After compiling verajusenc^ link the verajocaldl file with the necessary object files: 

Id -G T:Bsyinbolic -o /vera_local.dl o_£iles^.vera_user.o vera_kemel \ 

SyJnopsysjnc., 
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ojiles - The ojiles are the compiled UDF object files. 
SunOS 

To create the verajocaldl file with object files: 

CO -c -I$VERA_HOKE/lib c_files vera_juser.c 
cJUes - The cjiles are the UDF files you are linking with Vera, 
After compiling verajuserx^ link the verajocaldl file with the necessary object files: 

Id -o vera_local . dl o_^files vera_user.o vera_kemel 
ojiies - The ojiles are the compiled UDF object files. 

15.3.3 Object Files and vera^mti.dl for VHDL 

The verajmtldl file is a dynamic library file that you must manually generate when you create your 
UDF object files. There are two steps you must take to create the verajocaldl file: 

1 . Compile verajuserx and all your library files with the appropriate position independent code options i:o 
create the verajocaldl file. 

2. Link the verajocaldl file with the necessary object files and libraries. 
This process is platform-specific, 

HPUX 

To create the verajmtldl file with object files: 

CO rc +z -ISVERA^HOME/Iib affiles vera.user.c 

OR 

gcc -fpic *I$VERAJHOME/lib affiles vera_user.c 

cJUes - The cjiles arc the UDF files you arc linking wth Vera. 

After compiling verajuserx^ link the verajmtldl file with the necessary objea files: 

Id -b +e syssci_prod_entry errno -o vera_piti,dl o.files \ 
vera_user-o vera_kerneljnti -Ic 

oJUes - The ojiles are tiie compiled UDF object files, 
Solaris 

To create the verajmtldl file with object files: 

cc -K pic -c -I$VERA^HOME/lib c_ files vera_user,c 
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OR 

gcc -fpic -c -I, -I$VERA_HOME/lib c_fxles vera^user.c 

c JUes - The cjiles are the UDF files you are linking with Vera. 

After compiling verajusenc^ link the vera^mtLdl file with the necessary object files: 

Id -G -Bsymbolic -o vera_mti.dl o^fxles vera_user.o vera_kemel_mti \ 
-Isocket -Insl -lintl -Ic 

oJUes - The ojiles are the compiled UDF object files. 
SunOS 

To create the verajtntldl file with object files: 

cc -c -I$VERA_HOME/lib c_files vera_user.c 
c Jiles " The cjiles arc the UDF files you are linking with Vera. 
After compiling verdjuserx^ link the verajtntldl file with the necessary object files: 

Id -o vera_inti.dl o^filGS vera_user,o vera_kemel_mti 
o Jiles - The o Jiles are the compiled UDF object files. 

15.4 PLI Support Procedures 

Vera provides several procedures designed for PLI support 
vera_num_argO 

The vera_num_argO system function returns the number of arguments in the UDF that it is called in. 
The syntax is: 

vera„mim_arg () ; 

vera_get_argO 

The vera_get_argO system function returns a Vera data structure with the values in the specified argu- 
ment The syntax is: 

vera j«t_aro ( index) ; 

index - The index is an integer that specifies which data structure to return. 

The function returns the data structure associated with the specified argument The values returned 
should be used without any modifications. You can free it manually or by calling vcra.freelargO- 
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verajree_arg() 

The vera_free_argO system function frees a Vera data structure returned by vera_get,arg(). The syn- 
tax is: 

ver«_free_«rg (vera_data) ; 
verajdata - Verajlata is a pointer to the data structure you want to free. 

When vera_free_argO is called, it frees all memory allocated by vera_get_argO, including bit and 
string data, 

vera_retum_vaiueO 

The vera_T€tum_vaiueO system function sets the return value fox the UDF. The syntax is: 

vera_returti_value (vera_data) ; 

yerajtata - VeTa_data is a pointer to the data structure you want to return a value fix)m. 

The vera_retum_valueO system function returns the value associated with the specified data structure. 
It may be called only one time before returning. 

Note - Calling vera_retum_value0 multiple times before returning may 
cause a crash. 



vera^ut_argO 

The vera jut_argO system function sets the return value for a var argument. The syntax is: 

vora_put_a.rsr ( index, v^rai^da. ta ) ; 
ini - The index specifies which argument is assigned a value, 

verajiata • Wera_data is a pointer to the data structure containing the value to be assigned. 

When the vcra_put_argO system fimction is called, it assigns the value associated with the given data 
structure to the specified argument 

15.5 Handling Special Events 

When an HDL and Vera start or reset, your C functions may need to perform certain operations b<tforc 
they are ready to be used. Also, they may need to know when Vera and the HDL arc passing control 
back and forth. To handle these events, you can write miscellaneous functions, which you call in llie 
Vera UDF Table (see Section 15.3,1, "Vera UDF Table"), 
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When one of the predefined reasons occurs, the miscellaneous routine is called. Along with the data pa- 
rameter, it transfers a parameter to the function call that is based on why the routine was called. Table 
15-2 lists the VERAJtEASONS and their values. 

Table 15-2 VEIIA.REASON Values 



VERA.REASON 


Value 


VERA_REASON_INIT 


1 


VERA_RBASON_RESET 


2 


VERA_REASON_RESUME 


3 


VERA_REASON„SUSPEND 


4 


VERA_REASON_EXIT 


5 



This function can be used to handle special events or set conditions necessary before UDF calls can be 
made. 
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Examples: User-Defined Functions 

This is an example of UDF usage. This example covers the following constructs: 

• UDF code 

• UDF call from Vera 

• RUN script 

This example includes these files: 

• udfcodex 

• testvr 

• RUN (a run script) 

udfcode.c 

# include <stdio.h> 

• inc lude • vera_us er . h ' 

/* task $upctask( integer i, string strl, var string str2) ; */ 

int upctask{int data) 
{ 

int nargs = vera„niim_arg ( ) , i ; 
vera_data *argl, *arg2, *arg3; 
vera_data retval ; 

char *procn = 'upctask*, *strl, *str2; 

if (nargs != 3) 
{ 

fprintf (stderr, 'upctask: Wrong nianber of args (%d)\n*, nargs); 
exit(l); 

} 

argl = vera_jget_arg(0) ; 
arg2 = vera_jget_arg(l) ; 
arg3 = vera_get_arg(2} ; 
if (argl->type 1= VERA^INT) 
{ 

f print f (stderr, 'upc task: 1st arg is not an integer\n"); 
exit(l) ; 

} 

if (arg2->type i= VERA^STRIHG) 
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fprintf (stderr, "upctask: 1st arg is not a stringXn"); 
exit (1) ; 

} 

if (arg3->type != VERA_STRING) 
{ 

fprintf (stderr, "upctask: 1st arg is not a stringXn'); 
exit (1) ; 

} 

i = argl ->cLa ta . int_val ; 
strl = arg2->dat a. string; 
str2 = arg3->dat a. string; 

fprintf (stderr, 'task %s: i=%d strl='%s' str2='%s' \n' , procn, i, 
strl, str2); 
retval.type = VERA_STRING; 
re tval. data. string = "arg task, task"; 
vera_put_arg ( 2 , tretval) ; 
vera_free_arg(argl) ; 
vera_free_arg(arg2) ; 
vera_f ree_arg (arg3 ) 

> 

/* function string $upcfijnc (integer i, string strl, var string str2); */ 
int upcfimclint data) 

{ 

int nargs = vera_niain_arg {) , i ; 
vera_data *argl, *arg2, *arg3; 
vera„data retval; 

char *procn = •upcfxinc*, *strl, *str2; 

if (nargs != 3) 
{ 

fprintf (stderr, 'upcfunc: Wrong niomber of args (%d)\n", nargs); 
exit(l) ; 

} 

argl = vera get arc ( 0 ) ; 
arg2 = vera_get_arg ( 1) ; 
arg3 = vera_get„arg ( 2 ) ; 
if (argl->type != VERA_IKT) 
{ 

fprintf (stderr, 'upcfunc: 1st arg is not an integer\n*>; 
exitd); 

} 

if (arg2->type != VERA^STRING) 

i . - - ' r>:.-- - - 

fprintf (stderr, "upcfxmc: 1st arg is not a stringXn*); ^ 
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exit(l) ; 

} 

if (arg3->type != VERA_STRING) 
{ 

fprintf (stderr, 'upcfunc: 1st arg is not a stringXn'); 
exit (1) ; 

} 

i = argl->data.int_val; ■ . 

strl = arg2->data. string; 
str2 = arg3->data. string; 

fprintf (stderr, -func %s: i=%d strl='%s' str2=' %s ' \n* , procn, i, strl, 
str2) ; 

retval-type = VERA_STRING; 

retval- data -string = "arg func, func"; 

vera_put_arg {2 , tretval ) ; 

retval. data. string = Tet fiinc, f\inc*; 

vera_retum_value ( tretval ) ; 

vera_free_arg{argl) ; 

vera_f ree_arg (arg2 ) ; 

vera„f ree_arg { arg3 ) ; 

} 

/* misc procedure calls */ 

int upcmiscKint reason, int data) 
{ 

printf ("upcmiscl called with data=%d and reason=* ,data) ; 

switch (reason) 

{ 

case VERA_REASON_INIT:printf (•VERA_REASON_INIT\n*) ; break; 
case VERA_REASON_RESET : print f ( • VERA_REASON_RESET\n" ) ; break; 
case VERA_REASON_RESDME:printf CVERA-REASON^RESUMEXn') ; breaks- 
case VERA_KEASON_SUSPEND:printf (•VERA_REASON_SUSPEND\n«) ; break; 
case VERA_REASON_EXIT:printf (•VERA_REASON__EXIT\n")'; break; 
default: printf (•????????????????\n") ; break; 

} 

} 

int upcmisc2(int reason, int data) 
{ 

printf (•upcmisc2 called with data=%d and reason=" ,data) ; 

switch (reason) 

{ 

case VERA_REASON_INIT : printf ( • VERA_REASON_INIT\n* ) ; break; 
case VERA^REASON_RESET : printf ( • VERAu_REASON_RESET\n • ) ; - break; 
case VERA^REASONLRESOMErprintf (-VERAuJ^EASON^M 
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case VERA_REASON_SUSPEND:printf ("VERA_REASON_SUSPEND\n*) ; break; 
case VERA__REASON_EXIT:printf ("VERA_REASON_EXIT\n*) ; break; 
default: printf ( " ????????????????\n« ) ; break; 

} 

} 

testvr 

# inc lude <vera_de fines . vrh> 

task $upctask( integer i, string strl, vax string str2); 

function string $upcfunc (integer i, string strl, var string str2); 

program test 
{ 

string a, b, c; 

a = "I am a'; 

b = •! am b*; 

c = 'I am c ■ ; 

$upctask(l, •! am here",c); 

printf (•a='%s' b='%s' c= ' %s ' \n^ , a,b, c) ; 

c = $upcfunc(l,a,b) ; 

printf (•a='%s' b='%s' c= ' %s ' \n* , a,b. c) ; 

} 



RUN 

#I/bin/csh -f 
#!/bin/csh -fxv 

set ARCH = Vusr/local/bin/ncpu' 
echo $VERA_HOME 

na ,-rf vera_user.h vera_user.c vera_kemel libVERA.a vera_cs_local \ 
vera_local.dl vera_user,o udfcode.o test.vxo sirov simv.daidir \ 
verilog.log >& /dev/null 

cp $VERA_HOME/lib/{vera_user .h,vera_user.c, vera_kemel, libVERA.a) . 
sed -e V\/\* user entries go here \*\//s/^, *$/#include "udf,cV\ 
vera_user.c > temp 

rm - f vera_us er , c 

cat - teit^) > vera„user.c «END 

# include <stdio-h> 
♦include "udf .h* . 

-END ■ ■ .-..A.......... ^» 
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rm -f ten^ vera_local .dl 
set csrc = (vera_user.c udfcode.c) 
set cos = (vera_user.o udfcode.o) 
setenv SSI_I*IB_FII/ES , /vera_local . dl 
vera - cmp t es t . vr 
if {$status) exit 1 
switch ($ARCH) 
case "SOL*: 

cc -DNOJVERILOG.SIM -K pic -c $csrc |& egrep -v "'vera_user. c; $ | \ 
'^udf code , c : $ ' 

Id -G -Bsyrobolic -o vera_local . dl $cos vera_kemel -Isocket -Insl \ 
-lintl -Ic 

cc -DNO_VERILOG_SIM -o vera_cs_local $csrc libVERA.a -Isocket -lnsl\ 
-lintl -lin |£c egrep -v "^vera_user .c:$ j ^udfcode.c: $' 

vcs -q test.vshell -1 vcs*log -P $VERA_HOME/lib/vera_pli. tab \ 
$VERA_HOMEyiib/libSysSciTaskpic.a >& /dev/null 

if ($status) exit 1 

breaksw 

case ■SUN4*: 

gcc -DN0_VERILOG_SIM -fpic -c $csrc 
Id -o vera_local . dl $cos vera^kemel 
chmod +w libVERA*a 
ranlib libVERA.a 

gcc -DNO_VERILOG_SIH -o vera_cs_local $csrc libVERA.a -Im 
vcs -q test.vshell -1 vcs, log -P \ ^ 

$VERA_HOME/lib/verajli,tab $VERA.HOME/lib/libSysSciTask.a \ 

>t /dev/null 
if ($status) exit 1 
breaksw 

case "HPUX-IO*: 

gcc -DNO_VERILOG_SIM -fpic -c $csrc 

Id -b +e syssci_prod_entry ermo -o vera_local.dl \ 
$cos vera_kernel -Ic -Im 

gcc -DNO_VERIIiOG_SIM -o vera_cs_local $csrc libVERA.a -Im 

vcs -q test.vshell -1 vcs. log -Mupdate=l -gen_c -P \ 

$VERA_HOME/lib/vera_pli . tab $VERA_HOME/lib/libSysSciTaskpic . a \ 
-I*DFIAGS -a archive_shared^ -Idld >& /dev/null 

if ($status) exit 1 

breaksw 



endsw 
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vera -cmp test.vr 

if ($st:atus) exit 1 

- /vera_cs_local test • vro 

verilog test.vshell -1 verilog.log +vera_load=test .vro 
./simv -f-vera_load= test. vro 

zm -rf vera_user.h vera„user.c vera^kemel libVERA.a vera_cs_local \ 
vera_local , dl vera„user.o udfcode.o test. vro siinv simv.daidir >& \ 
/dev/null 
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16. VERA-SV API 

This chapter introduces Vera-SV API, which is used for hardware/software co-verification and 
distributed simulatioru It includes these sections: 

• Vera-SV Motivations 

• Vera-SV Overview 

• The Vera Side 

• The C/C++ Side 

• Troubleshooting 

• Backward Compatibility 



16.1 Vera-SV Motivations 

The key motivations behind the development of Vera-SV are hardware/software co-verifica- 
tion, distributed simulations, and a master-slave configuration where the C side controls the 
simulation. 



1 6,1 .1 Hardware/Software Co-Verification 

HW/SW co-verification involves the concurrent development of software and hardware. In 
this methodology, software components (drivers, debuggers, application programs) are com- 
piled to run at full speed on a workstation and interact in a bus-cycle accurate fashion with a 
simulated hardware model 

This API supports HW/SW co-verification by enabling C/C++ applications (e.g* drivers, dcj- 
buggers, application programs) and Vera programs to execute remote calls to eadi other, 
C/C++ applications are compiled into native binary executables and run on the host worksta- 
tion at full speed. They use the API to interact wifli hardware modek (Verilog, VHDL, C) nm- 
ning imder the control of a Vera program. 

With the API, C/C++ applications call tasks and functions in flie Vera program which then 
probe, stimulate, and monitor tiie hardware model. In a similar fashion^ the Vera program can 
react to an event generated by the hardware model and call the C/C++ application to notifj' it 
of an asynchronous event (like an interrupt, for instance). 
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1 6.1 .2 Distributed Simulation 

Distributed simulation is often used with, but not limited to, HW/SW co-verification. Distrib- 
uted simulation involves verifying large designs by partitioning verification tasks to run con- 
currently across multiple processors. This API supports distributed simulation by enabling 
multiple Vera programs and C/C++ applications to execute remote calls to each other across a 
network of workstations. For example, an application program on one host can be executing 
assembly code for a particular processor and interacting via the API with Vera programs on 
another host that simulate the board containing the processor. 



Note - Both UNIX and NT workstations are supported. 



1 6.1 .3 Master-Siave Configuration 

The traditional and default setup for Vera/C interfaces has Vera as the master. In this setup. 
Vera controls the simulation time and determines how the calls to C are made* However, 
sometimes it is useful to have the C side control ihe simulation completely and dictate the 
simulation time along with all simulation activity. Vera-SV provides the flexibility for such a 
setup, 

16.2 Vera-SV Overview 

The Vera System Verifier API is a collection of predefined Vera functions and a C program- 
mer's library. Together, they enable the development of hardware and software co-verification 
and distributed simulation environments. 

With this API, verification engineers can build interfaces between system components mod- 
eled with Vera and C/C++. This API enables Vera programs to communicate and synchronize 
with other Vera programs and with independent C/C++ applications via remote calls. 

The API's remote call technology permits a natural way to model system components: 

• Remote calls initiated from Vera programs are inherently multi-threaded (Vera threads, not 
UNIX/NT threads). This allows yoiir hardware models to mimic the concurrency of real hard- 
Wcue, For example, a Vera program can have multiple tasks waiting concurrently for tixeir 
remote calls to execute. While these suspended tasks are waiting, other Vera tasks will continue 
their execution. 

• Remote calls from a client to a server may be either blocking or non-blocking. Blocking calls 
have an implicit handshake; they wait for the server to execute the call before returning. Non- 
blocking calls are equivalent to message passing; they send the call to the server and return 
immediately (possibly before the server has a chance to execute the call), 

• The remote call mechanism is effidentiy passes laige chunks of data between simulations.. 
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The API creates point-to-point (1-to-l) connections. A connection consists of a server/client 
pair; the server is on one side of the connection; the client is on the other. A single process may 
create both client and server connections, but it must not connect to itself. 

A single process may also create multiple server and client connections/ but each server con- 
nects to exactly one client, and each client connects to exactly one server. 

Using iiie API is straight-forward and consists of these three basic steps: 

1. Define a network of server/dient i.e,, components which will talk to each other. 

2. Bring up the servers /clients network. 

3. Execute the remote calls. 



16.3 The Vera Side 

This section describes how to make remote calls from Vera programs to other Vera programs, 
AH connections between the Vera programs need to be defined and brought up before remole 
calls are made. The Vera functions that define the network of connections are 
vsv„make„serverO and vsv_make_clientO- 



16.3.1 Initiaiizing Connections 

Vera has a set of functions used to initicilize connections. 
vsv_make_sefverO and vsv_fnake_clientO 

Vera provides the system functions vsv_make_serverO and vsv_make_client0 to initialize 
coimections. The syntax is: 

v»v_iaak«_«erver(port, authentication I, verbose]}; 
v«VLinake_cli«nt ( *host' , port, authentication) ; 

port - The port indicates a virtual port number used for a single client/server pair during a 
session. It can be any positive integer, 

authentication • The authentication specifies an authentication code to use while bringing up 
connections. If the server specifies a zero value, no audientication is needed for ti\e 
connection, and the value provided by the client is discarded. If tite server authentication 
is not zero, the client and server authentications must match. 

verbose - The verbose modifier can be omitted or VERBOSE. If it is set, the server outputs 
messages if errors occur while processing remote client submissions, 

host " The host is a string that specifies the IP address or host name of tiie server. . 
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Both these functions return a non-zero integer identifier that is used for the subsequent use of 
the connection. A returned zero-value means the function failed and the connection has not 
been set up. 

Each call to vsv_make„serverO must be matched by one and only one call to 
vsv_make_client() in another Vera simulation. 

This is an example of the vsv__make_server() and mak€_hostO system functions; 
integer servcoim; 

servcoim = vsv„inake_server (5555, 0, VERBOSE); 
integer clientl, client2; 

clientl = vsv_inake_client (•localhosf , 5555, 0); 
client2 = vsv„iiiake„client ('171.64.195.82', 7777, 0) ; 

This example creates two clients for the host. The authentications for each client are 0, which 
matches the server authentication. Each client/ server pair is opened on a separate port 

vsv_up_connectionsO 

Once all connections have been configured, the vsv_up_connectionsO system function is used 
to make all of them active. The syntax is: 

vsv_up_coimoctions{ tiineout) ; 

timeout - The timeout specifies the time limit allowed to bring up connections. It is specified in 
seconds per connection. 

The function returns 0 if all connections have been activated or -1 otherwise. The 
vsv_up_connectionsO system function can ordy be called once in each simulation. If it fails, 
none of the connections made by vsv_make_clientO or vsv_make_server() are usable, and you 
need to re-start the simulations if you want to use the Vera-SV APL 

After a successful activation,' the connections are ready to process and/or submit remote calls. 
This is an example of the vsv_up_connectionsO system functioru 
vs v_up_connec t ions (30); 

In tiiis excimple, if tiie Vera program has previously configured a server and a client coimec- 
tion, vsv_up_connections(30) times out after 60 seconds. 

vsv_close„connO 

Cormections can be dosed with the vsv_close_cormO system function. The syntax is: 
v«v_clo«c_coixn ( connect i on ) ; 

connection - The connection specifies which connection to dose. It is the integer identifier 
passed by vsv_make_servcrO when the cormection is created. 
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This function return -1 if an error occurs, otherwise returns zero. 
This is an example of the vsv_close_conn() system function: 

iiyconn=vsv_jtiake_client (*localhost*, 5555, 0); 
vsv_close_conn (mycoim) ; 

16.3.2 Servicing Remote Calls 

When a Vera program is a server, all global Vera task and functions are available as remote 
procedures to the client, and servicing remote calls is transparent. At the end of every cycle, 
the Vera simulation engine will process arriving remote calls. The remote calls will then be dis- 
patched to the tasks and functions in the Vera program. When tiiese tasks and functions com- 
plete, their returned values and VAR parameters are automatically sent back to the dient. 

Remote calls run simultaneously with the main Vera application. It is up to the user to syn- 
chronize the remote calls with the main execution if necessary. 



16.3.3 Submitting Remote Calls 

These are the two system functions which can submit calls from a Vera program to a remote 
application: vsv_calLfxmcO and vsv_calLtaskO* The syntax to call them is: 

V8v_call^fiiac( connection, tiine„iaode, jfunc_i2aine, retura_vaiue opt^args}}; 

v«v_caai_t:ack( connection, time_mode, task_name [, opt„args] ) ; 

connection ~ The connection is the connection identifier returned by vsv_make_clientO* 

timejmode - The timejnode must be WAIT, which suspends simulation time until the call is 
completed, or NO_WAIT, which allows the simulation time to advance while the call is in 
execution. ^ ' '"^'* 

funcjnameJtaskjname - The funcjname or iaskjname is a string witti the name of the remote 
procedure to be executed. ^ - ^ 

retumjoalue - The rehirnjoalue must be a variable (not an expression) that matches thle type 
returned by the remote functioru The retumjoalue can be of type integer; bit vector, or 
string. The value of fee variable is set by tiie remote function calL 

opt^args - The optjirgs are optional arguments that must match the corresponding 

arguments on the function or task side. The optjirgs can be of type integer, bit vector, 
or string. They can be variables if the remote argument specifies a var argimient, or 
expressions if the remote ar^gument is not of type vat 

These are examples that illustrate valid uses of arguments: 

Remote prototype Valid local calls 
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integer result, c, i[10]; 
string mystr; 
bit [5:0] r; 

INTEGER factorial (NONVAR/ INTEGER) vsv_call„f unc ( . . . factorial , result , 5 ) 

vsv_call_f unc ( factorial , result , i [ 5 ] ) 
vsv_call_f unc ( , . . factorial , result , c ) 

printValue ( NONVAR/STRING NONVAR/BIT ) vsv„call_task( , , .printValue, *foo',2 'hxl) 

vsv_call_task{- . . printValue, ,inystr,r) 

myfoo ( VAR/ STRING VAR/ INTEGER ) vsv_call_task ( . . -irryf oo^itQrstr, c) 

The vsv_call_funcO and vsv_call_taskO system functions suspend the calling Vera thread un- 
ta the call has completed. Other Vera threads that are not suspended can continue to run, as 
long as they do not advance simulation time. Both vsv_call_£uncO and vsv_call_taskO return 
a value of 0 on successful completion and a non-zero value otherwise. 

This is an example of the vsv_calLfunc() and vsv_call_task0 system functions: 

integer results- 
integer myconn; 
bit [7:0] b = 8'bxxxOOOzz; 

inyconn = vsv_iaake_client ( *localhost' , 3333, 0, VERBOSE); 
vsv_up_connections ( ) ; 

if {vsv_call_func (myconn, NO_WAIT, "factorial', result, 5) != 0) 
printf ( *Error in factorial call: %s\n' , vsv^et_conn_err () ; 

if (vsv_call_task(myconn, WAIT, *printValue' , "BitValue", b) != 0) 
printf ( "Error in printValue call: %s\n* , vsv_get_conn„err < ) ; 

16.3.4 Managing errors 

When any of the API functions return an error value, the vsv_get_conn_errO function can be 
called to obtain a message describing the cause of the failure. The syntax is: 

v«v_ff«t_coiin„err ( ) ; ■ ^ 

The vsv_get_corm_crrO returns a message describing the cause of the failure. Possible reasons 
of failure are a: dropped cormectiorv mismatched authenticatioiv mismatched task/function 
prototype, etc 

This is an example of the vsv_get_corm_€rrO system function: 

if (vsv_call_task(conn, NO_WAIT, •myfoo', inystr, c)' != 0) 
printf ( 'Error in myfoo call : %s\n* , vsv_jget_conn_err ( ) ) ; 
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1 6.3.5 Master-Slave Configuration 

Vera-SV provides the vsv_wait_for_mputO and vsv_wait_for_done() system tasks to facilitate 
the use of Vera in a Master-Slave environment where Vera is the slave (server) and a C/C-f-t- 
process is the master (client). 

vsv.waitJorJnputO 

The vsvjwait.f or_uiputO system task suspends the current Vera thread imtil a remote client 
function request is received. The syntax is: 

vsv_wait„f or_input {wait_mode) ; 

waitjmode - The waitjmode can be WAIT, which suspends both the Vera thread and the 
simulation time until a remote client function request is received, or NO„WAlX which 
allows other Vera threads to increment the simulation time as necessary. 

When the vsv_wait_f or JnputO system task is called, the current Vera thread is suspended. If 
the wait mode is set to WAIT, the simulation time is also suspended. All Vera threads waiting 
for the simulation time to advance are suspended as well. However, if the wait mode is set to 
NO.WAIT, other concurrent Vera threads continue to execute and advance simulation time. 
As soon as a remote client function request is received, flie thread resumes execution. If there 
are already remote calls being processed at the time the call is made, the task does not sus- 
pend the Vera thread, 

vsv_wait_for_doneO 

The vsv„wait.for_doneO system task suspends the current thread until all of the remote client 
calls have been completely processed and the replies returned. The syntax is: 

v«v_WB.it_f or_done ( ) ; 

As soon as replies have been returned to the client, the thread restimes execution. 

Note - The remote client call is considered to have completed when a 
reply is returned, even if backgroxmd Vera threads that were created 
by tiie remote call are still active. 

This is an example of the vsv.wait Jor JnputO and vsv.wait.for.doneO system tasks: 

repeat ( 3 ) 
{ 

vsv_wait_for_input(WAIT) ; 
vs v_wait_f or_done ( ) ; 

} 
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This example suspends the current thread and the simulation time until a remote call is re- 
ceived. The requested function is executed, and simulation time is advanced during that exe- 
cution as necessary. Then the thread suspends imtil the next call is made. This cycle is 
repeated three times. 

16.3.6 Separate Client and Server Example 

This example demonstrates how one Vera program calls a function in another Vera program. A 
program running on a host named t'riger calls the "multiply" function in a program ruiming 
on "ceti". 

Program Running on Host "cat!" 

# include <vera„def ines , vrh> 

program ceti 
{ 

event rigel_called_me? 
integer connection; 

// the program running on rigel will call this 

function integer imiltiply (integer a, integer b) 
{ 

multiply = a * b; 

trigger (ONE_BIAST , rigel„called_me) ; 

} 

// make this program a server 

connection = vsv_make_server (2222 , 0 , VERBOSE) ; 
if (connection 0) 

error { *vsv_make_server failure Vn" } ; 
if ( vs v_up_connec t i ons (30)) 

error (*vsv_up_conhec t ions failureXn'); 

// wait for rigel to call me 
sync (ALL, rigel„callecL;ne) ; 
printf(*ceti is doneXn'); 
vsv„close_conn (connection) ; 

} 

Program Running on Host "rige!" 

# include <vera_de fines . vrh> 

program rigel 
{ 

integer connection; 
integer product; 
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// make this program a client 

connection = vsv_inake_client ( *ceti' , 2222 , 0) ? 
if (connection == 0) 

error ( *vsv_make_client f ailure\n' } ; 
if (vsv_up_connections (30)) 

error ( *vsv_up_connect ions failureXn*); 

// have remote host multiply 3x7 

if (vsv_call_func (connection, WAIT, ^multiply* , product, 3, 7)) 

error ( •vsv^call.f xinc f ailure\n' ) ; 
printf(*3 * 7 = %d\n', product); 
vsv„close_conn( connection) ; 

} 



16.3.7 Combination Client-Servers Example 

This example demonstrates how two Vera programs can call each other: Each Vera program 
operates as both a client and a server. 

One program runs on a host named "ceti"; one on a host named "rigel". Both programs irdtisd- 
ize a local semaphore to be empty and fork a thread to wait on that semaphore* Each progr«im 
then calls a remote task in the other progrzim to unlock the semaphore for the other prograim* 

Program Running on **cetr 

# inc lude < ver a_de f ines . vrh> 

program ceti 
{ 

integer server, client; 
integer semaphore_id; 

// the program running on rigel will call this task 
task ceti_unlock( integer semaphore_value) 
{ 

printf (*rigel unlocked me\n*); 
s emaphore_pu t ( s emaphor e„id , semaphore_value ) ; 

} 

// initialize my semaphore to empty 

semaphore„id = alloc (SEMAPHORE, 0, 1, 0); 
s erver = vs v_make_server (2222,0, VERBOSE ) ; 
if (server ~ 0) 

error ( *vsv_make_server failure \n' ) ; 
client = vsv_jnake_client ( 'rigel ',333 3,0) ; 
if (client ~ 0) 

error ( *vsvjnake_client f ailureXn* ) ; 
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if (vsv_up_connections (30) ) 

error ( *vsv_up_connections f ailure\n' ) ; 
fork 
{ 

// unlock rigel 

if (vsv_call„task (client, NO_WAIT, *rigel_unlock* , 1) != 0) 
error ( *iHilock on rigel f ailiireXn') ; 

} 
{ 

// wait for rigel to unlock me 

s emaphor e_ge t ( WAIT , s emaphor e„id , 1 ) ; 

} 

join 

printf(*ceti is doneVn') ; 
vsy„close_conn( server) ; 
vsv_close_conn{ client) ; 



Program Running on "rigel" 

# include <vera_def ines .vrh> 

program rigel 
{ 

integer server, client; 
integer semaphore_id; 

// the program running on ceti will call this task 
task rigel_unlock (integer semaphore_value) 
{ 

printf(*ceti unlocked roe\n*); 

s emaphor e_pu t ( s emaphor e_id , s emaphore_value ) ; 

} 

// initialize my semaphore to en^ty 

semaphore_id = alloc (SEMAPHORE, 0, 1, 0); 
server = vs v_make„server (3333,0, VERBOSE ) ; 
if (server == 0) 

error (*vsv_make_server failureXn*); 
client - vsv„make_client {• ceti* ,2222, 0) ; 
if (client == 0) 

error ( *vsv_make_client f ail\ire\n' ) ; 
if ( vs v_up„connec t i ons (30)) 

error ( •vsv_up_connections f ailureXn* ) ; 
fork 
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{ 

y/ xinloc3c ceti 

if (vsv_call_task (client, NO.WAIT, *ceti_\inlock* , 1) 1= 0) 
error (^unlock on ceti failureXn*); . 

) 
{ 

// wait for ceti to xmlock me 

seiaaphore_get (WAIT, semaphore_id, 1); 

} 

join 

print f ( *rigel is doneXn* ) ; 
vsv_close„conn (server) ; 
vsv_close_conn (client) ; 



16.4 The C/C++ Side 

This section describes how to make remote calls between' C/C-M- applications and Vera pro- 
grams. All connections between the C/C++ applications and Vera programs need to be de- 
fined and brought up before remote calls are made. 

The API procedures for C/C++ applications are similar to their Vera coimterparts, and only 
their prototypes are described in this document 

For a complete description of the API procedures please see the *'$VERA_HOME/lib/vsv,h'' 
fUe. 

These aie the prototypes: 

extern void *vsv_MakeServer ( 
int port, 

int authentication 
); 

extern void *vsv_JlakeClient ( 
char *host, 
int port, 
int authentication 
); 

extern int vsv_UpConnections ( 
int timeout 
); 

extern int vsv_CallFunc ( 

void * connection, 

char *name, 
vsvArgT *retumVal, 
int nuitiberArgs , 

vsvArgT *args 
); 

extern int vsv^CallTask ( - f _ 

void *conaection, 
char *naiBe, 
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vs vCa llWaitingT 
int 

vsvArgT 



wait^ 

nxunberArgs , 
*args 



); 

extern int vsv_CloseConn { 
void * connection 
); 

extern char *vsv_GetErrorMesg (void) ; 



In addition to the above, the API also provides procedures for C/C++ applications that will 
function as servers. C/C++ servers need to pre-register functions and tasks that will be made 
available to clients by calling vsv_RegisterFunc and vsv_RegisterTask API procedures. Also, 
C/C++ servers must explicitly call vsv_AnswerCaIls to service incoming function and task 
calls from the clients. 



Note - This is not true if the application is both a server and a client, 
in which case incoming calls will be automatically serviced if the 
application is waiting for a vsv_CallFunc or vsv_CallTask to 
complete. Here are the API prototypes for servers: 



16.4.1 , Calling a Vera Task from a Oprogram Example 

This example demonstrates how a C-program running on host named "ceti" calls a task in a 



extern int vsv_RegisterFunc ( 

void *connection, 

char *naine, 

vsvArgT * r e tumVal , 

int nuinberArgs , 

vsvArgT *args, 

vsvFimcCbT fcb 
); 




extern int vsv_AnswerCalls ( 

void * connection, 

vsvCallHandlingT how 



); 



Vera program running on a host named "rigel". 



C Program Running on "ceti" 

♦include <vsv.h> 
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main 0 
{ 

vsvArgT arg; 
void *cormection; 

/* make this program a client of rigel */ 

connection = vsv_MakeClient (*rigel',2222,0) ; 
if (connection == NULL) 

perror (vsv_GetErrorMesg() ) ; 
if <vsv_UpConnections (30 ) ) 

perror ( vsv_GetErrorMesg ( ) ) ; 

/* call the remote task passing an integer argument set to 1 */ 
arg.vtype = VSV_NONVAR._ARG ; 
arg.atype = VSV_INTEGER_ARG ; 
arg.<3ata.integerVal = 1; 

if (vsv_CallTask( connect ion, *xinlock', VSV_WAIT, 1, &arg) ) 
perror ( vsv_GetErrorMesg ( ) ) ; 

(void) print f ( *ceti is done\n' ) ; 

(void) vsv„CloseConn( connection) ; 
exit (0) ; 



Vera Program Running on "riger 

# include <vera_def ines . vrh> 

program rigel 
{ 

integer connection; 
integer semaphore_id; 

// the program running on ceti will call this task 
task imlock( integer semaphore_value) 
{ 

printf ( *ceti unlocked me\n* ) ; 

semaphore jut ( s emaphore_id , s emaphor e_value ) ; 

} ' 

// initialize my semaphore to empty 

Eemaphore_id = alloc (SEMAPHORE, 0, 1, 0); 

// make this program a server 

connection = vs v_roake_server ( 2 22 2 , 0 , VERBOSE ) ; 
if (connection == 0) 

error ( • vsv_jEnake_server f ai liare \n • ) ; 
if ( vs v_up_connec t ions (30)} 

error { •vsyjup_connec t ions f ailtire \n ' ) ; 
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// wait for ceti to unlock me 

seinaphore_get (WAIT, semaphore_id, 1); 
printf (*rigel is done\n*); 
vs v_cl OS e„conn (connection) ; 

} 

16.4.2 Calling a C Function from a Vera Program Example 

This example demonstrates how a Vera program nmning on host named "rigel" calls a func- 
tion in a C program running on a host named ''ceti'". 

Vera Program Running on "rigel" 

# inc lude < vera_de f ines . vrh> 
program rigel 

{ 

integer connection, product; 

// make this prograun a client 

connection = vsv„make_client ( *ceti* , 3333 , 0) ; 
if (connection == 0) 

error ( *vsv_make_client failure \n' } ; 
if (vsv_up_connections (30) ) 

error ( *vsv_up„connections f ailureXn* ) ; 

// call the remote multiply function on ceti 

if (vsv„call_func (connection, WAIT, ^multiply', product, 8, 9)) 

error (*vsv_call„func failure\n') ; 
printf (^product = %d\n', product); 
vsv_close_conn (connection) ; 

) 

C Program Running on **ceti" 

# inc lude <vs v , h> 
static int done = 0; 

static void multiply (vsvArgT *retumVal, int numberArgs, vsvArgT *args) 
{ 

/* set the return value */ 

retumVal->data.integerVal = 

ar gs [ 0 ] . data . int egerVal * args [ 1 ] . data . integerVal ; 
done = 1; 



Vera 4.0 User's Manual 



Chapter 1 6, VER A-S V API 307 



mainO 
{ 

vsvArgT retumVal, args[2]; 
void *connection7 

/* make this program a server */ 

connection = vsv_MakeServer (3 333 , 0 ) ; 
if (connection ~ NULL) 

perror (vsv_GetErrorMesg() ) ; 

/* define the arg\jment types accepted hy the multiply function */ 
retximVal.vtype = VSV_VAR_ARG; 
retumVal.dtype = VSV„INTEGEIL.ARG; 
argsIO] ,vtype = VSV.NONVAiUARG; 
args[0] .dtype = VSV_INTEGER_ARG ; 
argsfl] .vtype = VSV_NONVAR_ARG; 
argsll] .dtype = VSV.IKTEGEIL.ARG; 

if (vsv_RegisterFunc (connection, *xnultiply* , tretumVal, 2 , args , multiply ) ) 

perror {vsv_GetErrorMesg() ) ; 
if (vsv„UpConnections (30 ) ) 

perror (vsv_GetErrorMesg() ) ; 

/* wait for multiply to be called once */ 
while ( I done) 
{ 

if (vsv_AnswerCalls (connection, VSV_DO_PENDING) ) 

perror (vsv_GetErrorMesg { ) ) ; 
sleep (1) ; 

> 

(void) vsv_CloseConn (connection) ; 
exit(O); 



16.5 Troubleshooting 

If the vsv.up.connectionsO S3rstem function is failings use the VERBOSE option with 
vsv„make_serverO and make sure that zombie UNIX/NT processes are not still running from 
previous simulations. You may also want to increase the timeout parameter passed to 
vsv_up_connectionsO. 

If vsv_up_conncctionsO works, but your network is slow and your remote calls are failing 
with errors such as "Connection timeout no response," try setting these environment vari- 
ables: 

setenv VSV_HEAD_TIMEOOT 600 
setenv VSV_BLOCKEP„TIMEOOT 120 
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16.6 Backward Compatibility 

For backward compatibility, these system function rumes from previous versions of Vera are 
still in use with their corresponding current names: 

Table 16-2 Previotis and Current VSV System Fimctions 



Previous 


Current 


call_fimc 


vs v_cal l_f unc 


call_task 


vsv_call_task 


close_conn 


vsv_close_conn 


get_conn_err 


vsv„get„conn_€rr 


inake_client 


vs v_inake_c 1 lent 


makers erver 


vsv_inake_server 


up„connec t ions 


vsv_up_connections 
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17. Testbench Setup and Usage Notes 

This chapter discusses general setup and usage notes for creating and running simulations with Vera 
testbenchcs. It includes these sections: 

• Creating Tcstbenches for Verilog Designs 

• Creating Tcstbenches for VHDL Designs 

• VHDL Testbench Usage Notes 

1 7.1 Creating Testbenches for Verilog Designs 

This section discusses the creation of Vera testbenches using the Vera template generator. It also details 
how to connect Vera testbenches to Verilog designs through the test-top file and through direct connec- 
tions. Finally, it details how to set up multiple clocking domains. 

17-1.1 Vera Template Generator 

Vera's template generator creates a simulation framework and a Vera program template from an HDL 
module definition. The syntax to invoke the template generator is: 

vera -tem teinplate_options BDL^fxlenam& 

tempUUejjpdons - The templaiejoptions are listed in Table 17-1. 

Table 17-1 Template Options 

Option Defuiition 

-c Specifies clock signal 

-d specifies cLxiinp file 

-xxav Uses Magellan for simulation control 

-t Specifies Verilog module name - 

HDL JUename - The HDLJilencme is the HDL file from which the template is generated. 



-c 

The -c option specifies the clock signal on the HDL module. The syntax is: 
-c clocJc^signal 

clock^signal • ,llie clock jsignal i& the signal you want to connect SystemClock to. 
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When the -c option is invoked, the defined clock signal is connected to SystemClock, and it is spec- 
ified as CLOCK in the interface specification. If this option is omitted, SystemClock is used as the 
sampling clock. 

-d 

The -d option specifies the dump file name. The syntax is: 

-d filename 
filename - The filename is the name of the dump file. 

-nav 

The -nav option invokes Magellan for simulation control, source level debugging, and waveform dis- 
play. The syntax is: 

-nav 

To use Magellan or any other graphic package, you need the corresponding PLI tasks linked to your 
HDL executable, 

-t 

The -t option specifies the top HDL module name. The syntax is: 
-t filename 

filename - The filename is the name of the top HDL module from which the template is being 
generated. 

The -t option is mandatory. It is used to generate three output files:^/emimc,test_top,v.^/e/w2m€.if,vrh, 
and filename. \T,tmp, 

This is an example module from a Verilog model file sample.v: 

module myfsmdsig, osig, ot:hers, Clk) ; 

input isig; 

output osig; 

incut [3:0] others; 

input Clk; 

endmodule 

Given this Verilog model and module, this command line is invoked to generate a Vera template: 
vera -tern -t myfsm -c Clk -nav -d myfsm.dun^ san^le.v 

^Vhen the command line is invoked, this test top file myfshutestjtop.v is generated, which contains the 
instances of vcra_sheli and the specified module with all signal connections: 
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module itiyf sln_test„top; 
paraIneter Simula tion_cycle = 100; 
reg SystemClock; 
wire isig; 
wire osig; 
wire [3:0] others; 
wire Clk; 

assign Clk = SystemClock; 

vera_shell vshell ( 

.SystemClock (SystemClock) , 

,myfsm_isig<isig) , 

.inyfsin__osig(osig) , 

, my f smoothers (others) , 

,inyfsitL_Clk(Clk) 

); 

myfsm dut( 

.isigdsig) , 
.osig (osig) , 
.others (others) , 
.Clk(Clk) 

) ; 

initial begin 

SystemClock = 0; 
forever begin 

# {siiaulation_cycle/2) 

SystemClock - -SystemClock; 

end 

end 

initial begin 

$duinpf ile ( •inyf sm, dun?)* ) ; 
$du«?)vars (0, my f smites t_ top) ; 

end 
endmodule 

Invoking the command line also generates the interface file myfsnuif.vtii: 

interface myfsm { 

output isig OUTPUT^EDGE OOTPOT_SKEW; 
input osig INPUT„EDGE; 

inout [3:0] others INPOT_EDGE OOTPUT.EDGE OUTPUT_SKEW; 
input Clk CLOCK; 

} 

^. 
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Finally, the command line generates the Vera program template file myfsm.vr.tmp: 

#define OOTPUT_EDGE PHOLD 
tdefine OUTPUT.SKEW #1 
#define INPUT„EDGE PSAMPLE 
# include <vera_def ines . vrh> 

program inyfsin_test 

// declaring interface, vca signal, and classes.. 

# inc lude *iny f sin , i f . vrh ' 

// define vca_defn, class, instance here if necessary 

{ // Start of myfsm_test 

} // end of program myf sm_test 



17.1.2 Connecting Vera Testbenches to Verilog Designs 

There are three ways to connect Vera testbenches to Verilog designs: through a test-top file, by driving 
Verilog submodules through direct signal connections, and through the multiple module support dis- 
cussed in Chapter 12. 
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17.1 .2.1 Connecting Testbenches Through the Test-top File 

The test-top file method of connecting testbenches to the DUT connects the Vera testbench to the Ver- 
ilog DUT through a test-top. The DUT and the Vera shell file (.vshell) rest on the test-top, and all signal 
connections are made through that test-top. The test-top instantiates the DUT and the Vera shell mod- 
ule. Vera drives the Verilog DUT through the shell module. Finally, the clock generator is on the test- 
top. Figure 17-1 shows the schematic of this configuration. 



f 



Clock Generator 



Device 
Under Test 



Vera Shell File 



Interface Specification 



test-top file 



VeraTestbench 



I I 



Figure 17-1 Test-top method of testbench connection 
Given this setup, the steps to connect a Vera testbench to a Verilog arbiter (rrarb.v) are: 

1 , Generate the template files from the Verilog source code using: 
vera -tern -t rraxb -c elk rrarb.v 

This generates the interface file and the test-lop file. The interface file specifies the signal 
connections between the DUT and the testbench. If you use the same signal names in the Vera 
testbench as the names in the DUT, you do not need to modify the interface file. 

The clock generator is created in the test-top file. 

2, Compile the Vera testbench source code using: 
- vera -en?) rrarb.vr 

Hus generates the conqJiled Vera object files (-vro) and the Vera shell file (.vshcll),^ 
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3. Run the simulation using: 

vera -run verilog rrarb. test„top.v rrarb.v rrarb.vshell \ 
+ver a_prog=rrarb , vro 

Using this configuration, these steps connect the testbench and PUT without any further work. 

The files for this arbiter are: 

• rrarb.v (the Verilog design) 

• rrarkvr (the Vera testbench) 

The DUT design generates these files: 

• rrarbJfvrh (the interface file) 

• rrarb,testjtop.v (the test-top file) 

• rrarb.vsheU (the Vera shell file) 

• rrarb.vro (Vera object file) 

rrarb.v 

module rrarb (request, grant, reset, elk) ; 
input [1:0] regues t ; 
output [1:0] grant ; 
input reset; 
input elk; 
wire winner; 
reg last_winner; 
r eg [1:0] grant ; 
wi r e [1:0] next_gr ant ; 

assign next_grant [0] 

= -reset &( request [0] & 

( -reques t [ 1 ] 1 las t^winner ) ) ; 

assign next_grant [ 1 ] 

= -reset & ( request [1] t 

(-request [0] - ( --last_winner) ) ; , 

assign winner 

= -reset t -next_grant [0] & 

( last_winner | next_^rant[l] ' ) ; 

always ecposedge elk) begin 
last_winner = winner ; 
grant = next_grant ; 

end 
endmodule 
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rrarb.vr 

tdefine OOTPUT_EDGE PHOLD 
tdefine OUTPUT.SKEW #1 
#define INPUT„EDGE P^AKPLE 

# inc lude <vera_def ines . vrh> 

# include • r rarb .if. vrh " 

program rrarb_test 
{ 

integer i; 

trace ( ON, PRCX3RM1, 0 ); 
// reset 

rrarb, request [03 = I'bO; 

r rarb . request [ 1 3 = 1 ' bO ; 

rrarb. reset = 1; 

ei rrarb. reset = 0; 
// simple requesting 

@1 rrarb. request [03 = I'bl; 

ei rrarb. grant == 2'bOl; 

ei rrarb. request [03 = I'bO; 

rrarb, request [13 = I'bl; 

@1 rrarb, grant == 2'blO; 

rrarb. request [13 = I'bO; 
// round- robin test 

ei rrarb. request [03 = I'bl; 

rrarb. request [13 = I'bl; 

ei rrarb. grant =:= 2'bOl;// shoud get grant 0, since last was 1 
§1 rrarb. grant =:= 2'blO;// keep asserting both port^ should get grant 1 
rrarb. request [03 = I'bO; 
rraxb. request [13 - I'bO; 
} // end of program rrarb_test 
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17.1 .2.2 Directly Connecting Testbenches to the DUT 

Direct connections to the DUT eliminate the need for a test-top file. Instead, the testbench is directly 
connected to the DUT through the HDL node method of signal declarations. Using this configuration, 
you must explicitly define how the testbench signals and DUT signals are connected. It is important to 
note that under this configuration, the clock must be defined in the DUT and connected to the testbench 
through a signal declaration. Figure 17-2 shows the schematic for this configuration. 



Device 
Under Test 



Qock Generator 



Vera Testbench 



Figure 77-2 Direct connccuon between testbench and DUT 

Given this setup, the steps to connect a Vera testbench to a Veiilog arbiter (rrarkv) are: 

1 , Compile the Vera testbench source code, including the interface specification, using: 
vera -cmp rraxb.vr 

The interface specification is generally included in the rrarbAf.vrh file and included in the rrarLvr 
file. This generates the compiled Vera object files (.vro) and the Vera shell file (.vshell). 

2, Rim the simulation using: 

vera -nm verilog rrarb.v rrarb. vshell +vera_prog=rrarb,vro 
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Using this configuration, the clock must be defined in the DUT and connected to the testbench through 
the interface specification. Further, each signal connection must be done using the hierarchal pathnames 
in the HDL node method, 

The files for this arbiter are: 

• rrarb.v (the Verilog design) 

• rrarb.vr (the Vera testbench) 

• rrarbJfvrh (the interface file) 

The DUT design generates these files: 

• rrarb.vskeU (the Vera shell file) 

• rrarb.vro (Vera object file) 



rrarb,v 

module rrarb? 

parameter Simula tion_cycle = 100 ; 

wire (1:0] request ; 

wire reset ; 

reg elk ; 

wire winner ; 

reg last_winner ; 

reg [1:0] grant ; 

wire [1:0] next_grant ; 

initial 
begin 

elk = 0 ; 

forever begin 

# (Simula tion_cycle/ 2) 

elk = -elk ; - • 

end ^ ' ii": 

end 

assign next _ grant f 0 1 • 
= -reset &( request [0] & (-request II] | last_winner) ) ; 

assign next grant f 11 

= -reset & ( request(l] & (-requestlOl | -last_winner) ) ; 

assign winner 

= -reset & -next_grant [0] & ( last_winner | next^granit [1] ) ; 
always @(posedge elk) begin 
last_winner = winner ; 
grant = next„grant ; 

end 
endmodule 
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rrarbJf.vrh 

#ifndef INC_RRARB_IF_VRH 
#define INC_RRARB_IF„VRH 

interface rrarb 
{ 

output [1:0] request OUTPUT_EDGE OUTPUT_SKEW verilog„node 

• rrarb . reques t " ; 
input [1:0] grant INPUT_EDGE verilog.node " rrarb . grant • ; 
output reset OUTPUT__EDGE OOTPUT_SKEW verilog_node 'rrarb. reset" ; 
input elk CLOCK verilog_node " rrarb. elk*; 

) 

v€rilog_node CLOCK "rrarb. elk*; 
#endif 

rrarb.vr 

#define OUTPDT.EDGE PHOLD 
#define OUTPUT_SKEW #1 
#define INPUT_EDGE PSAMPLE 
#include <vera_def ines , vrh> 
# include ■ rrarb. if .vrh" 

program rrarb_test 
{ 

integer i; 

trace ( ON, PROGRAMED ); 
// reset 

rrarb. request [0] = I'bO; 

rrarb. requestd] = I'bO; 

rrarb. reset =1; 

&1 rrarb, reset = 0; 
// simple requesting 

ei rrarb, request [ 0] '= I'bl; 

ei rrarb. grant — 2'bOl; 

ei rrarb. request [0] = I'bO; 

rrarb.requestfl] = I'bl; 

ei rrarb. grant == 2'blO; 

rrarb. request [1] = I'bO; 
// round-robin test 

01 rrarb. request [0] = I'bl; 

rrarb, request {13 = I'bl; 

ei rrarb. grant == 2'bOl; // should get grant 0, since last was 1 

ei rrarb -grant == 2'blO;// keep asserting both port, should get grant 1 
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rrarb. request [0] = I'bO; 
rrarb. request [1] = I'bO; 
} // end of program rrarb„test 



17.1.3 Multiple Clocking Domains 

There are two ways to run a simulation with multiple clock domains: create multiple clock generaton; 
in the DUT source files, or create multiple clock generators in the test-top file. 

If you want to use multiple clocking domains with the test_top generators, you should add these lines of 
code after the SystemClock declaration in the test-top file: 

initial begin 

clockname = 0; 
forever begin 
# perlod/2 

clockname - --clockname 

end 

end 

clockname - The clockname is the name of the clock generator. 

period ' The period is the period of a single clock cycle, measured in nanoseconds. 



1 7,2 Creating Testbenches for VHDL Designs 

To integrate Vera testbenches with VHDL designs, you must develop the simulation fiMiework, This 
section includes discussions on each of the files required to integrate Vera testbenches with VHDL de- 
signs and how they are made, instructions on how to connect Vera testbenches to VHDL designs, and 
instructions on how to generate multiple clocking domains. 

17.2.1 _ Files for Test-top Connections 

VHDUs version of the tcst^op connection r&quires three key files: design^top^ deslgnjop.vhdy 
designjtntf.vhd and vercLtnL Each of these files is discussed here. ' " 



17.2.1.1 design Aop 

The desigfutop file is the test top file used to connect the VHDL design to the testbench. To generale 
the top file, use the -vfadl or -vhdl -top compile options: 

vara -cop -viidl -top filename 

J. 

filename - Tte jfilename is the name of the Vera testi)ench source file. This file contains the interfai:e 
specification for the testbench. 
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Using the -top switch with the -vhdl switch generates the top file. When the file is generated, you must 
rename it to filename.iop. 

After generating the top file, you must modify it: 

1 . Instantiate the DUX You must define the DUT component 

2. Create a DUT instance with a valid port m^. 

3. Define the signals referenced by the port map. 

4. If the DUT has a system clock, connect the DUTs system clock to the Sys temClock signal. If the 
DUT does not have a system clock, modify the generated system clock's half period as necessary for 
your simulation. 

Warning - Do NOT modify the vmc.mti entity or architecture. 

The top file is a source file that is modified only if the Vera interface changes (signals are added, delet- 
ed, or renamed) or if the DUT interface changes. If neither changes, the top file docs not need to be 
modified or regenerated. 

17.2.1 .2 cfes/flrn_top.vhd and des/gnjntf .vhd 

The designjiop.vhd file is generated using the -vhdl switch alone: 

vera -cmp -vhdl filename 

When the -vhdl switch is used alone, the/i/cmimejntf.vhd and filename J.opyhd files are generated. 
These files should not be renamed or modified. If you need to modify the design_iop.\hd file, edit the 
designXop file. These files must be compiled with the VHDL source files. The -vhdl switch checks for 
the existence of z filename Xop file. If the file does not exist, a warning is issued and the 
filenamejiop.vhd file is not generated, 

VHDL tasks to be called fi-om Vera slibuld be encapsulated and included in the filename Jxyp.vhd file. 

Vcra*s global variables are copied into ihc filenmnejiap.yfhd file so that they can be viewed and de- 
bugged. They arc prcpended by var_. Only Vera variables of type integer, bit, and bitO are copied. 

Inside the filename JLop.vhd file is a reference to the Vera shared library vera_mtLdlL For VSIM to find 
this file, you must set LDJJBRARYJ'ATH to $VERAJ{OME/lib. 



17.2.1.3 vera.ini 

The initialization file vera^ini is required for the VSIM command. Vera first checks the current working 
directory and then the $VERAJiOME directoiy. This file must be present for Vera to run. 

The vera,im file contains lines of this syntax: 
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name_^ t oken va I u e_ t oJcen 

namejoken - The valid name_tokens arc: 

vcrajoad 

vera_niload 

vcra_mIoad_de£in€ 

vera„stop_oii_error 

vera„continue„on_error 

vera_cxit_on_erTor 

vera_finish_on_end 

vera_debug.on_crror 

vcra_text_debug 

vera.scmaphore^size 

vera_rej^on_si2e 

vera_mailbox„size 

vera_randoin_seed 

vera_rand48_seed 

map 

value Joken - The value joken varies depending on the namejtoken. The valid tokens are listed in the 
subsequent definitions of the namejokens. 

verajoad 

The verajoad token specifics an HDL object (.vro) file to be used with the simulation. The syntax is: 
verajoad filename 

filename - The filename is the .vro object file to be used. Multiple files can be specified by separating 
them with commas, 

vera_mload 

The vera_inload token specifies a .vri file that lists multiple object files to be used with the simulation. 
The syntax is: 

vera_&load filename 

filename - The filename is the .vri file that lists the object files to be used. Multiple files can be 
specified by separating them with commas. 

vera_mload_define 

Tlie vera_mIoad_define specifies a text macro. The syntax is 

verajniload_def£M m^cro^name-value 
macro^name - The macro jume is the string of text to be substituted for. 
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value ' The text macro is optionally set to value. 

Text macros defined at compile time are particularly useful when using the conditional compilation di- 
rectives. 

vera_stop_on_error 

The vera_stop_on„error token causes the simulation to stop immediately when a simulation error is 
encountered. Hie syntax is: 

vera_Btop_oii_crror swi tch 
switch - The switch is used to turn the mode on, A value of U **true," "on," or **y^" t*™® the mode on. 
The default setting is to execute the remaining code within the present simulation time. 

vera_continue„on_error 

The vera.continue_on_error causes the simulation to continue after a verification error is encoun- 
tered. The syntax is: 

vera_continue„on_error swi tch 

switch - The switch is used to turn the mode on. A value of 1, **truc " "on " or "yes" turns the mode on. 

This token causes the simulation to continue when verification errors (such as failed expects) occur. 
This token overrides the vera_exit_on_error token. 

vera_exit_on_error 

The vera_exit_on_crTor token causes the simulation to be terminated when a simulation error is en- 
countered. ITie syntax is: 

v«ra„exit_oa„crror switch 
switch - The switch is used to turn the mode on. A value of 1, **truer "on " or "yes" turns the mode on. 
The default setting is to stop the simulation and return to the HDL shell. . i 

vera_finish_on_end 

The vera_£mish_oii_end token specifies that the simulation is finished when a simulation nm is com- 
pleted. The syntax is: 

ver a_f ini«h_on_cnd swi t ch 
switch - The switch is used to turn the mode on. A value of 1, "true/* "on,** or "yes" Uims the mode on. 
The default setting is to stop the simulation and return to the HDL shell. 

— ' 
Syryppsyislnc. 
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vera_debug„on_error 

The vera_debug.on_error token invokes a debugger when a verification error (such as a failed expect) 
is encountered. The syntax is: 

vora_detoug_on„crror switch 

switch • The switch is used to turn the mode on, A value of 1, "true,** "on " or "yes** turns the mode oia. 

The vcra_debug_on„ciTor token determines the debugger used when a verification error is encoun- 
tered. If the HDL simulator has control when the error occuars, the simulator's debugger is invoked. If 
Vera has control when the error occurs, Vera's debugger is invoked. , . . 

If the vcra_debug.on_error token is not used, the behavior depends on the particular HDL simulator, 
vera_text_debug 

The vcra_text_debug token launches the text debuggw when an error occurs. The syntax is: 

ver«_text_debug switch 
switch - The switch is used to turn the mode on. A value of 1, "true,** "on,** or "yes** turns the mode on, 

vera_semaphore_6i2e 

The vcra_semaphore_sizc token specifies the maximum number of semaphores within the simulatioii. 
The syntax is: 

vftraL_0emaphore_8lze size 
size - The size specifies the maximum number of semaphores within the simulation. 
The default limit is 2048. 

vera_region_size 

The Ycra_region_size token specifics the maximum number of regions within the simulation. The s^rn- 
tax is: 

vera_region_«ixo size 
sizfi - The size specifies the maximum number of regions within the simulation.. 
The default limit is 256. 

vera„mailbox_size 

The vcra„mailbox„size token specifics the maximum number of mailboxes within the simuladon. The 
syntax is: 

vera.nallbaxe«_size size 
size - The size specifies die maximum number of mailboxes within the simulation, ' 
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The default limit is 256. 
vera_random_seed 

The vera„randoin_seed token sets the seed for calls to the randomQ system function. The syntax is: 

vera_random_Beed seed 
seed - Hie seed can be any valid expression evaluating to a number. 

vera_rand48„seed 

The vera_random„seed token sets the seed for calls to the rand480 system function. The syntax is: 

vera_raiid48_«oed seed 
seed - The seed can be any valid expression evaluating to a number, 

map 

The map token maps Vera enumerated types to VHDL enumerated types. The syntax is: 

map vera^enum_naiae nvm vhdl_enuml vhdl_ent[m2 * . , vhdl_enuittN 
yera_enum_name - The vera_enum_name is the Vera enumerated type category. 
num - The num specifies how many elements there are in the category, 

vhdljenumN - The vhdLenumN is the VHDL enumerated type to which the Vera type is mapped. 

When the map token is executed, each Vera enumerated type (up the specified number) is sequentially 
mapped to the specified VHDL name. 

For example, in Vera, an enumerated type is defmed as: 

enum vera.color = VERA_RED, VERA„YELLOW, VERA_GREEN, VERA.BLUE; 

In VHDL, an enumerated type is defined as: 

type VhdlColor is {VHDL_RED, VHDL.YELLOW, VHDL_GREEN, VHDL_BLtJE} ; 

To equate the two, use the map command: 

map vera_Color 4 VHDL_RED VHDL_YEIA/)W VHDL_GREEN VHDL„BLUE 

17.2.1.4 vera 

The vera command is also supported by VSIM: 

vera token_Bame token^value 
These token and value combinations are allowed: 
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debug 

load filename 
mload filename 

debug 

The debug token launches the Vera debugger when invoked. The syntax is: 
vera debug switch 

switch - The switch is used to turn die mode on. A value of 1, **true," "on/* or "yes" turns the mode on. 
load 

The load token specifies an HDL object (•vro) file to be used with the simulation. The syntax is: 

vera load filename 

filename - The filename is the .vro object file to be used. Multiple files can be specified by separating 
them with commas, 

mload 

The mload token specifies a .vrl file that lists muldple object files to be used with the simulation. The 
syntax is: 

vera mload filename 

filename - The filename is the ,vrl file that lists the object files to be used. Multiple files can be 
specified by separating them with commas. 

17.2.1.5 VSIM Commands in vera.ini 

Vera supports the VSIM Restart command. However, the Save and Restore commands are not support- 
ed ' ' ' : ■ - - — . 

17.2.2 Connecting Vera Testbenches to VHDL Designs r^.^-- 

Yon can connect Vera testbenches to VHDL designs using two methods: connecting the testbench 
through a test-top configuration, or directly connecting the testbench to nodes within the design. 
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1 7.2.2.1 Connecting Testbenches Through the Test-top 

The test-top method of connecting a Vera testbench to a VHDL design connects the testbench through 
the test-top file {designjop.vhd). The test-top file is generated from the desigrutop file. The DUT is 
connected directly to the Vera testbench through the Vera interface and through the VHDL interface. 
Figure 17-3 shows the schematic for this configuration. 



Clock Generator 



1 



Device 
Under Test 



Vera Interface 



VHDLJntf.vhd File 



Vera Testbench 



test-top file 



Figure 17-3 Test-lop method of testbench connection 
Under this configuration, the clock generator is in the test-top (designjtop,vhd) file. 
Given this setup, the steps to connect a Vera testbench to a VHDL arbiter (rrarh.vhd) arc: 
L GcneratethcjTarA.ropfilefrom the Vera source code using: . i,'. Z \ - \' 

'vera -cn?) -vhdl -top rrarb.vr 
This generates the rrarbJop file. 

2, Edit the rrarbJop file to include the definition and instantiation of the DUT. 

3. Generate the VHDL interface file (rrarbjntf.vhd)^ test-top file {rrarbjtopyhd)^ and compiled Vera 
object file (jrarb.vro) using: 

vera -ctt^ -vhdl rrarb.vr 
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This generates the interface file, test-top file, and compiled Vera object file from the Vera source 
code and the previously generated rrarbjop file. These files should not be edited. If you edit the 
rrarbjLop.vhd file and recompile the Vera source code with the -vhdl switch, you lose the edits you 
made. 

4. Run the simulation with the VHDL interface file (rrarbjmtf,vhd), the test-top file {rrarbjtop^vhd), tiae 
Vera object file (rrarb.vro) and the VHDL DUT (rrarb.vhd). 

The files from this arbiter are: 

• rrari^.vW (the VHDL design) 

• rrar6,i/!vr (the Vera interface file) 

• mzri.vr (the Vera testbench) 

When compiled, these files arc generated: 

• rrarbjntf.vhd (the VHDL interface file) 

• rrarbjop,vhd (the test-top file) 

• rrarb.vro (Vera object file) 

rrarb.vhd 

library IEEE; 

use IEEE. std_logic_1164. all; 
use IEEEJstd_logic_arith.all; 
use IEEE. std„logic_unsigned. all; 

entity rrarb is 
port ( 

request : in std_logic_vector (1 downto 0); 
grant : out std_logic_vector (1 dovmto 0); 
reset : in Btd„logic: 
elk : in std_logic 

); 

end entity rrarb; 

architecture rrarb_arch of rrarb is 
signal winner ; ctd^logic z- ' 0 ' ; 
signal last_winner : std_logic := '0'; 

signal next_grant : std_logic_vector (1 downto 0) "OO*; 
begin 

next_grant ( 0 ) <= (not reset) and ( request (0) and 

((not request (1)) or last_winner) ) ; 
next_grant (1) (not reset) and ( request (1) and 

((not request (0)) or (not last_winner) ) ) ; 
winner <= (not reset) and (not next^^rrant ( 0 ) ) and 

(last_winner or next_grant (1) ) ; 
process (elk) is 

begin ' ' - 
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if (clk'event and elk = '1') then 
last_winner <= winners- 
grant <= next_grant; 
end if; 
end process; 
end rrarb_arch; 

rrarb/rf.vrh 

#ifndef INC_RRARB„IF_VHH 
# define INC_RRARB_IF_VRH 

interface rrarb 
{ 

output [1:0] request OUTPUT_EDGE OUTPUT_SKEW; 

input [1:0] grant INPUT_EDGE; 

output reset OOTPUT_EDGE OUTPUT^SKEW; 

input elk CLOCK; 
} // end of interface rrarb 
#endif 

rrarfa.vr 

# define OUTPUT.EDGE PHOLD 
idefine OUTPOT_SKEW #1 
tdefine INPUT.EDGE PSAMPLE 
# inc lude < vera_de f ines . vxii> 
# include 'rrarb. if -vrh* 

program rrarb_test 
{ 

integer i; 

trace ( OK, PROSRAM, 0 ); 
// reset 

rrarb. request [0] = I'bO; 

rrarb. request[l] = I'bO; 

rrarb. reset = 1; 

01 rrarb. reset = 0; 
// simple requesting 

ei rrarb. request [0] = I'bl; 

@1 rrarb. grant == 2'bOl; 

ei rrarb. request [03 = I'bO; 

rrarb.request [1] = I'bl; 

ei rrarb. grant == 2'blO; 

rrarb.request [1] = I'bO; 
/ / rotmd-robin tes t 
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ei rrarb. request [03 = I'bl; 
rrarb.request [1] = I'bl; 

ei rrarb. grant == 2'bOl; // shoud get grant 0, since last was 1 
61 rrarb. grant == 2'bl0;//keep asserting both port, should get grant 1 
rrarb. request tO] = I'bO; 
rrarb. request II] = I'bO; 
) // end of program rrarb_test 

rrarb.top (after being modified) 

library IEEE; 

use IEEE. std_logic.ll64. all; 

entity rrarb„bench is 
end; 

architecture rrarb_bench_arch of rrarb_bench is 
# include rraxb . inc_vhd SIGNALS 
component rrarb 
port ( 

request : in std„logic_vector (1 downto 0); 
grant : out std_logic„vector (1 downto 0); 
reset : in std„logic; 
elk : in std^lcgic 

); 

end con^onent; 
component vmc„inti 
end component; 
begin 

sy6tem_clock <= not system_clock after 50 ns; 
rrarb_clk <=t system_clock; 
rrarb_inst: component rrarb 
port map ( 

request => rrarb_xequest4 

grant =>, rrarb_grant, 

reset => rrarb_reset, 

elk => rrarb_clk 

); 

vmc^int i_ins t : vmc^mt i ; 
# include rrarb . inc_vhd TASKS 
end; 
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17.2.3 Directly Connecting Testbenches to the DUT 

For VHDL, the model for directly connecting testbenches to the DUT is identical to using the test-top 
method, except for how the signals are connected. To dircctJy connect the testbench to the DUT, you 
must use the HDL node method when specifying the interface signals. 

The same arbiter from the previous section is included here with the connection made through direct 
nodes. Note the rrarbJf,vr file in particular. 

rrarfa.vhd 

library IEEE; 

use IEEE. std_logic_1164. all; 
use IEEE. std_logic_arith* all; 
use IEEE. std_logic_unsigned. all; 

entity rrarb is 
end entity rrarb; 

architecture rrarb_.arch of rrarb is 
signal winner : std_logic : = '0'; 
signal last„winner : std_logic := '0'; 
signal reset : std_logic := '0*; 
signal elk : std_logic := '0'; 

signal next_grant : std_logic„vector (1 downto 0) := •CO"; 
signal grant : std_logic_vector (1 downto 0) := *00"; 
signal request : std_logic_vector (1 downto 0) •CO*; 
begin 

elk <= not elk after 50 ns; 
next_grant (0) <= (not reset} and ( request (0) and 

((not request(l)) or last„winner) ) ; 
next_5rrant (1) <= (not reset) and ( request (1) and 

((not request (0)) or (not last^winner) ) ) ; 
winner <= (not reset) and (not next_grant ( 0 ) ) and 

(last_„winner or next_grant (1) ) ; 
process (elk) is 
begin 

if (elk' event and elk = '1') then 
last„winner <= winner; 
grant <= next^grant; 
end if 
end process; 
end rrarb_arch; 
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rrarb.if.vrh 

#ifndef INC_RRARB_IF_VRH 
# define INC_RRARB_IF_VKH 

interface rrarb 
{ 

output [1:03 request OUTPUT„EDGE OUTPUT_SKEW vhdl„node 

" / rrarb_bench/ rrarb_ins t / reques t • ; 
input (1:0] grant INPUT_EDGE vhdl_node 

"/rrarb_bench/rrarb_inst/grant" ; 
output reset OUTPUT_EDGE OUTPUT_SKEW vhdl_node 

•/rrarb„b,ench/rrarb_inst/reset" ; 
input elk CLOCK vhdl_node " /rrarb_bench/rrarb_inst/clk' ; 
} // end of interface rrarb 

vhdl_node CLOCK " /rrarb_bench/rrarb„inst/clk" ; 
#endif 



rrarb.vr 

# define OUTPUT_EDGE PHOLD 
#define OUTPUT_SKEW #1 
#define INPUT_EDGE PSAMPLE 
tinclude <vera„def ines . vrh> 
# include "rrarb.if .vrh- 
program rrarb_test 
{ 

integer i ; 

trace ( ON , PROGRAM ,0 ) ; 
// reset 

rrarb. request [0] = I'bO; 

rrarb. request CI] = I'bO; 

rrarb, reset = 1; 

ei rrarb, reset = 0; 
// simple requesting 

ei rrarb. request 10] = I'bl; 

ei rrarb. grant == 2'bOl; 

ei rrarb. request 10] = I'bO; 

rrarb. request [1] = I'bl; 

ei rrarb. grant == 2'blO; 

rrarb, request [1] = I'bO; 
// round- robin test 

ei rrarb. request (03 = I'bl; 

rrarb, request (13 - I'bl; 

ei rrarb. grant == 2'bOl; // shoud get grant 0, since last -was 1 
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Ql rrarb. grant == 2'blO; //keep asserting both port, should get grant 1 
rrarb. request [0] = I'bO.- 
rrarb. request [1] = I'bO; 
} // end of program rrarb_test 



rrarb.top (after being modified) 

library IEEE; 

use IEEE. std_logic_1164. all; 

entity rrarb_bench is 
end; 

eirchitecture rrarb_bench„axch of rrarb_bench is 
# include rrarb . inc„vhd SIGNALS 
component rrarb 
end component ; 
component vmc_mti 
end component; 
begin 

system_clock <= not system_clock after 50 ns; 

rrarb_clk <= system_clock; 
rr arb_ins t : rrarb ; 
vmc_mt i_ins t : vmc_int i ; 
# include rrarb . inc_vhd TASKS 
end; 



17.2.4 Multiple Clocking Domains 

To run simulations with multiple clocking domains, you must: 

1. Define an interface for each clocking domain you want to have in the interface file. 

2. Modify the filenamejbop.yhd file to instantiate the clock: 
— •ignal signal.name : •td_loglc : = ' 0 * ; 

3. Modify thcyz/enam^_top.vhd file to connect the clock and set the half period: 
clocJr_najne <= not clock^name after period ns; 



Note - You should have a clock for each interface. 
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17.3 VHDL Testbench Usage Notes 

This section includes several usage notes on using VHDL testbenches. 

17.3.1 Valid VHDL Signal Types 

Vera supports the assertion and querying of only these VHDL signal types: 

integer 
bit 

bit_vector 
stdjogic 
std_Iogic_vector 
std_ulogic 
std_ulogic_vcctor 
boolean 
boolean array 
enumerated types 



17-3,2 VHDL Plus Arguments 

In the vercLini file, you can specify plus arguments. The syntax is: 
Sirgument value 

argument - The argument is the name of the plus argument being defined. 

value - The value is the value of the plus argument There must be a space between the argument and 
the value. 

For cjtaniple, the VHDL equivalent to the Verilog plus aipiment +vcra_my_aig=100 is: 
ver a_my_arg= 100 

Note the space between the argument name and the argimient value. 

17.3.3 Features Not Yet Supported for VHDL 

These features are not yet supported for VHDL testbenches; 

• Multiple module support 

• Vera-CORE 

• Calling Vera tasks from VHDL 
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18. Compilation 



The Vera compiler accepts a Vera source program and generates binary Vera objects. This chapter dis- 
cusses the Vera compiler, preprocessor, and runtime control. It details Vcra's use with different HDL 
simulators, with C functional simulators, and as a stand-alone cycle-based simulator. This chapter in- 
cludes these sections: 

• Compiler Overview 

• Preprocessor 

• General Options 

• Compile Options 

• Running Vera with HDLs 

• Modular Compilation 

• Dynamic Lx)ading of Vera Object Modules 

• Running Vera Stand-alone 

18.1 Compiler Overview 

The compiler options are listed with a brief description in Table 18-1. 

Table 18- J Vera Compiler Options and Defmitions 
Option IXefinition 

-help Lists valid coii?>iler options 

-cmp Con^iles Vera source files 

*&lim Sets maximum nxanber of elements 

in arrays 

-«ix«l Invokes ansi preprocessor 

-g Invokes con^iler using debug 

information 

-h Updates .vrh file 

-hnu Updates .vrh file only >if it has 

changed 

-i Produces ASCII interface 

definition 

-Ip Conqpiles an IP core 

-max_error Sets the maximum num^r of errors 
before coit5>ilation failure 

' ' Conqpiles jji quiet iabde " 
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Table 18-1 Vera Compiler Options and Definitions (Continued) 



Option 




Definition 






Sets timescale 




■"top 


^x^ecLtes \tixjLt cop rj.j.e 






Processes VHDL top £lXe 






Specifies t:ext macoro 


-1 




Includes directory in seajrch path 


-PP 




Invokes preprocessor. 


-proj 




Creates Vera shell files from 
project file 


-nin 




Runs simulation 


-torn 




Invokes Vera template generator 




-c 


Specifies clock signal 




-d 


Specifies duir?) file 




-nav 


Uses Magellan for simulation 
control 




-t 


Specifies Verilog module name 


-V 




Returns the coit^siler version 
number 


-vcon 




Generates a .vcon file 



The options available for use with Vera-CS are listed with a brief description in Table 18-2, 
Table 28-2 Vera-CS Options and Definitions 
Option Definition 

-e Exits simulation on error 

-f Includes *vrl file in the con^ile 

-i Specifies initialization file 

Pauses simulation on error 
-t Invokes text-based debugger 



18-2 Preprocessor 

Vera programs are processed by a custom preprocessor prior to being translated by the compiler The 
preprocessor handles file inclusion, text macros, and conditional compilation. 

18.2.1 File inclusion 

A Vera source file can include another Vera source file by rcfcrencc using the include construct'Thc 
syntax is: '^^^ ^ ^ , , ^ 
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#include *path_to_file'' 

path Jo JUe - The pathjtojile can be the absolute or relative pathname to the include file. If the file is 
is in $VERA_HOME/lib, the quotes can be replaced by angled brackets (o), and only the file name 
is required. 

The <verajiefines.vrh> file should always be included. 

When the Vera compiler encounters an include statement, it replaces the include line with the entire 
file. 



Note - You cannot have spaces before the # in include statements. 



18.2.2 Text Macros 

Vera also supports text macros. The syntax to define a text macro is: 
#define macro^name ina.cro_V3Llue; 

macrojname - The macro^name is the name of the constant as it will be referenced throughout the Vera 
program* 

macro_yalue - The macro_yalue is the value assigned to the macrojname. It must be a constant 
numeric or word substitution. 

Note - You cannot have spaces before the # in text macros. 

This is an example of text macros; 

# define word^width 32 
#define ODTPUT_EDGE PHOLD 
#define OOTPtJT_SKEW #1 

#def ine INPUT_EDGE PSAMPLE ^ O ; 



18.2«3 Conditional Compilation 

The Vera preprocessor supports conditional compilation using #ifdef and #i{hde]r directives. The syntax 

is: 

iifdef jnacro^name 
tifnd«£ macro_namB 

macrojname - The macro juxme is the name of the text macro that determines the conditional. 

Note - You cannot have spaces before the # in conditional directives. 
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The ifdef directive conditionally compiles the text after the directive if the specified text macro has 
been defined. 

The ifndef directive conditionally compiles the text after the du^tive if the specified text macro has 
not been defined. 

Each of these directives can be used with the #else directive. The syntax is: 
telse 

The eke directive conditionally compiles the text after the directive if the previous ifdef or ifndef 
failed. 

Conditional compilation should be terminated using the #endif directive. Tbc syntax is: 
fendif 

This is an example of a conditional compilation directive block: 

# ifdef MACROl 

// This code is for MACROl 

telse 

// This code is not for MACROl 
tendif 

#ifndef MACROl 

// This code is not for BOO 

tendif 



18.3 General Options 

When the Vera compiler is invoked, several options can be called. The syntax to invoke the compiler is: 
verm genera.l_^optlons input_ filename 

generaLopOons - The general opdons used vrith the Vera compiler and their definitions are listed in Ta- 
ble 18-3, 

Table 18-3 General Options 



Option 


DeCnitlon 




— cmp 


Con^iles Vera soixrce code 




-X 


Includes directory in search path 




-pp 


Invokes preprocessor 




-proj 


Creates Vera shell files from project 


file . 
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Table 18-3 General Options (Continued) 



Option 


Definition 


-run 


Runs s imulation 


-tern 


Invokes Vera teit5>late generator 


-V 


Returns the conqpiler version nuitiber 


-vcon 


Generates a -vcon file 



input Jilename - The input Jilename is the name of the Vera source file being processed, 
-cmp 

The -cmp option compiles Vera source code. It is discussed in detail in Section 18.4. 
-I 

The -I option adds a specified path to the search path for include files. The syntax is: 
-I pati3_naine 

path^name - The pathjuime is the absolute or relative path to the directory you want to add to your 
search path. 

The -I option adds the specified path to all include files. If this option is invoked, be sure to declare all 
include files with respect to the specified path. 

-pp 

The -pp option invokes the Vera preprocessor. The syntax is: 

When the -pp option is used, the preprocessor is cxpUciUy used on the input file. When using the -cmp 
option, the preprocessor is automatically invoked. 

-pro] 

The -proj option is used when creating and using IP cores. The syntax is: 
-proj 

For more information on Vera-Core, see Chapter 13., **Vera-CORE." 
-run 

The -run option is used to run a Vera simulation with an HDL design. The syntax is: 
-run 

For more information on running simulations, see Section 18^, *^unning Vera with HDLs.*' 
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-tem 

The -tem option invokes the Vera template generator. The syntax is: 
-tem 

The Vera template generator is discussed in more detail in Section 17.1.1, "Vera Template Generator." 
-V 

The -V' option returns the version number of the Vera compiler. The syntax is: 

-V 

-vcon 

The -vcon option generates a ,vcon file for use with multiple module support. The syntax is: 
-vcon 

For more information on multiple module support, sec Chapter 12,, **Multiple Module Support," 

18.4 Compile Options 

The Vera compiler is primarily used to compile Vera source code using the -cmp option. The syntax is: 

vera -cxnp compil€r_opt2ons lnput_filBname output_ filename 
compilerjoptions - The compiler options and defmitions are listed in Table 18-4. 

Table 18-4 Vera Compiler Options 



Option 


Defioition, 




-alia 


Sets the maximum niimber of array 
elements 


-mjxmt 


Invokes tJtie 


ansi preprocessor 


-D 


Specifies a 


macro name 


-ff 

-h 


Updates the 


. vrh file 


-hnu 


tJpdates the 
has changed 


.vrh file only if it 


-i 


Produces an 
definition . 


ASCII interface 


-ip 


Generates an IP core 


-max_error 


Sets the maximum niimiber of errors 
before con5)ilation failure 
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Table 18-4 Vera Compiler Options (Continued) 



Option Definition 



-q Compiles in quiet mode, without a 

header 

-tiaescale Specifies a times cale 

-top Generates a VHDL test_top file 

-vhdl Generates VHDL template files 



inputJUename - The inputjilename is the name of the Vera source file being compiled. 
outputJUename - The outpvtJUename is the prefix of the ouQ)Ut file. 

When the -cmp option is invoked, the compiler generates the object file output Jilename.vro and the 
shell file output Jilename.vshelL If the ou^ut file is not specified, the prefix of the input file is used. 
Compiler options are used on top of this basic function. 

-alim 

The -alim option explicitly sets the maximum number of elements allowed in arrays. The default limit 
is 1024. The syntax is; 

-alia nujvbez' 

number - The maximum number of elements in an array is specified by <number>, 
-ansi 

The -ansi option preprocesses the Vera source code in ANSI mode. The syntax is: 
-D 

The -D option specifies a text macro. The syntax is: ' 

-D jnacro_name=value 
macro_name - The macrv^name is the string of text to be substituted for, 
ralue - The text macro is optionally set to value. 

Text macros defined at compile time are particularly useful when using the conditional compilation di- 
rectives, 

-9 

The -g option generates debugging information. The syntax is: 
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-h 

The -h option updates the ,vrh header file. The syntax is: 
-h 

The -h option automatically generates include files with global declarations from the Vera source code, 
-hnu 

The -hnu option updates the .viii header file only if it has changed. The syntax is: 
-hnu 

The -hnu option functions like the -h option except that it only updates the .vrfi file if there are changes 
to it 

-I 

The -i option generates an ASCII file containing the interface definition. The syntax is: 
-i 

The -i option generates a .vri interface file from the Vera source code. This is interface specification 
produces the corresponding generated interface file: 

input data_in[31;0] PSAMPLE 1 

output ackt31:03 PHOLD 0 

incut data_out[l:0] PSAMPLE 0 PHOLD 1 

input if_0 data_in 32 PSAMPLE 1 

output if_0 ack 32 PHOLD 0 

inout if„0 data_out 1 PSAMPLE 0 PHOLD 1 

The -ip generates Vera object files that can be used as IP cores. The syntax is: 
-ip 

When the -ip option is used, the Vera object files can be used without a runtime license. How IP cores 
arc used and generated is discussed in detail in Chapter 13., **Vcra-CORE.*' 

-max_error 

The -max_crror option specifies how many errors are encountered before the compile fails. The sjrntax 
is: 

-max„error number 

number - The number specifies the maximum nimibcr of errors the compiler can encounter before the 
compilation fails. 
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-q 

The -q option compiles the code in quiet mode. The syntax is: 

When the compiler is run in quiet mode, the header information is shortened and limited to only com- 
pile information. 

-timescale 

The -timescale option explicitly defines the simulation timescale inside the Vera shell file. The synta:c 
is: 

- tisieac&la=scal e 
scale ' The scale specifies the cycle length in nanoseconds. 
The -timescale option generates this statement at the top of the Vera shell file: 

* timescale scale 

-top 

The -top switch is used to generate a test_top file for VHDL designs. The syntax is: 
-top 

-vhdl 

The -vhdl switch is used to generate template fdes for VHDL designs. The syntax is: 
-vhdl 

1 8.5 Running Vera with HDLs 

Vera can be run with HDL designs using the -run option with plus arguments. The syntax is: 

vera -run filename args 
filename - The filename is the executable HDL file compiled with the Vera libraries. 
orgs - The plus arguments and their definitions arc listed in Table 18-5. 
Table 18-5 Plus Arguments ' 

Pius Argument Definition 

+vera_load Specifies a single object file 

+vera_mload Specifies a file wit:li a list 

of object files 

+vera_stop_on_error Execution stops on simulation 

error 
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Table 18-5 Plus Arguments {Continued} 



Plus Ax^ument 


Definition 




+vera_continue_on„€rror 


Execution continues after 
verification error 


+vera_exit_on„error 


Exits simulator on error 




+vera_f inish_on_end 


Exits simulator when 
simulation finishes 




+vera_debug_on_error 


Invokes Vera debugger on 


error 


+vera_t:ext_debug 


Launches the Vera text 
debugger on error 




+vera_s emaphore_s ize 


Specifies maximum number 
semaphores 


of 


-fvera_region_si2e 


Specifies maximum number 
regions 


of 


+ ver a_mai lbox_s i z e 


Specifies maximxim number 
mailboxes 


of 



+vera_load 

The +veraJoad argument specifies an HDL object (.vro) file to be used with the simulation. The syn- 
tax is: 

+vera_load= fl J ename 

filename - Tho. filename is the .vro object file to be used. Multiple files can be specified by separating 
them with commas. 

+vera_mload 

The +vera_inIoad argument specifies a ,vrl file that lists multiple object files to be used with the simu- 
iation. The syntax is: - 

+ver«_mlo«d= filename ' ' ■ 

filename - The filename is the ,vrl fde that lists the object files to be used. Multiple files can be 
specified by separating them with commas. 

+vera_stop_on_error 

The +vera_stop_on_erTor argument causes the simulation to stop immediately when a simulation error 
is encountered. The syntax is: 

+ver*_«top_on_«rror 

The default setting is to execute the remaining code within the present simulation time. 
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+vera_continue„on_error 

The -(-vera_continue_on_crror causes the simulation to continue after a verification error is encoun- 
tered. The syntax is: 

+vera_cont:inue_on_eriror 

This argument causes the simulation to continue when verification errors (such as failed expects) occur. 
This argument overrides the +vera_exit_on_error argument 

+vera_exit_on_error 

The +vera_exit_on_error argument causes the simulation to be terminated when a simulation error is 
encountered. The syntax is: 

+vera_exit_on_error 

The default setting is to stop the simulation and return to the HDL shell. 

+vera_finlsh„on_end 

The +vera_£inish_on„end argument specifies that the simulation is finished when a simulation run h; 
completed. The syntax is: 

+vera_fixiieh„on_ead 

The default setting is to stop the simulation and return to the HDL shell. 

+vera_debug_on_error 

The +vera_debug_on_erTor argument invokes a debugger when a verification error (such as a failed 
expect) is encountered. The syntax is: 

+vcra_debuff„on_error 

The +vcra_debug.on_crror argument determines the debugger used when a verification error is en- 
countered. If the HDL simulator has control when the error occurs, the simulator's debugger is invokwL 
If Vera has control when the error occurs, Vcra's debugger is invoked. ' ' 

If the +vera_debug_on_crn>r argument is not used, the behavior depends on the particular HDL simu- 
lator, * 

For example, with Vcrilog-XL, if the simulator has control, an interactive prompt is invoked. If Vera 
has control, the simulator invokes the interactive prompt when control passes back to the simulator. 

With VCS, regardless of where control is, the interactive prompt is invoked* 
+vera_text_debug 

The +vera_tcxt_debug argument is used to launch the Vera text-based debugger when an error is en- 
countered. The syntax is: 
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+vera„semaphore„size 

The +vcra_s€maphore_size argument specifies the maximum number of semaphores within the simu- 
ladon. The syntax is: 

+ ve r a_fi em&phor e_s xzo_sxze 
size - The size specifies the maximum number of semaphores within the simulation. 
The default limit is 2048. 

+vera_region_size 

The +vera_region„si2e argument specifies the maximum number of regions within the simulation. The 
syntax is: 

+ver a_rogion_si2e_si re 
size - The size specifies the maximum number of regions within the simulation. 
The default limit is 256. 

+vera_maHbox_sJ2e 

The +vera_mailbox_size argument specifies the maximum number of mailboxes within the simulation. 
The syntax is: 

+ ver«_maJLlboxe e_c i z b_s i ze 
size - The size specifies the maximum number of mailboxes within the simulation. 
The default limit is 256. 

18.6 Modular Compilation 

Vera programs can be compiled modularly at the program, task, and function levels. This allows you to 
make changes to individual files and reload the changes. There is no need to recompile or reload the 
HDL design code when compiling modularly. 

Modular compilation requires these conditions: 

• Variables declared in the top block must be declared external if tasks and functions 
compiled separately reference them. 

• Interface specifications in subroutine modules must match exactly those declared in 
the main program file. 

• Naming conflicts with subroutines can be resolved using local subroutine names. 



This is an example of two separate files linked at simulation time using modular compilation: 



ft 
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tst_chip,vr 

program test„my_chip 
interface iny„chip_prts { 

input reqO PSAMPLE vca rO; 

output ackO NDRIVE; 

inout[7:03 dadaO PSAKPLE NDRIVE ; 

input reql PSAMPLE vca rO; 

output ackl NDRIVE; 

inout[7:0] datal PSAMPLE NDRIVE; 

} 

port dt_prt { 
req; 
ack; 
data; 

} 

bind dt_prt portO { 

req iny„chip_prts . reqO ; 
ack iny_chip_prts , ackO ; 
data my^chipjrts.dataO; 

> 

bind dt_prt portl { 

req iny„chip_prts , reql ; 
ack i[iy_chip_pr ts . ackl ; 
data iny_chip_^rts . datal ; 



integer i , j ; 
bit dir; 

bit [7:0] my_data; " ' 

iextem task handshake vith dtjrt( 
bit direction, bit [7:0] h_data 

); 

vca ( ON , my_chip_p rt s ) ; 
for(i = 0; i < 10; i++) { 

iny_data = randomO; 

dir = i; 

handshake with portO(dir. iny_data) ; 

• } • . 

} 
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hs_tasks,vr 

port dt_prt { 
req; 
ack; 
data; 

} 

extern integer i, j; 

local task what_is_ij {) { 

printf(*top block i = %d j = %d\n', i. j); 

} 

task handshake with dt_prt (bit direction, bit [7:0] h_data) { 
eO.lOOO $req == I'bl; 
$ack = I'bl; 
ei $ack <= I'bO; 
if (direction) $data = h„data; 
else $data == h_data; 
what_is_ij () ; 

} 

These two files can be compiled separately to generate the object files, tst_chip.vro, and hsjasks.vro. A 
Vera list (.vrl) file lists the object files to be linked at simulation time. 

tst_chip.vrl 

tst_chip. vro 
hs_tasks,vro 

At simulation time, the argument +vera_mload = tst_cfap,vti must be called. 

1 8.7 Dynamic Loading of Vera Object Modules 

Vera testbenches can be loaded dynamically, without recompiling or reloading the HDL design. This al- 
lows for rapid development and easy assembly of regression tests. To enable dynamic loading. Vera 
provides these user-defined HDL tasks: 

$ver«_lo«.d(* filename. vro') ; 
$ vera.mload ( * f i 1 enaine . vr 1 * ) ; 

filename - The filename should be an object file when using $veraJoad or a Vera list file when ming 
$vera_mload. 

These tasks can be invoked from an interactive prompt or executed from a command file. However, 
they should not be invoked from within the HDL circuit description files, 
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Most often, you want to reset the simulation before loading a separate testbench. To reset a simulation, 
use the $reset command: 

$reset 

An entire regression can be ran by adding the appropriate sequence of resets, loads, and mloads to a 
command file and executing it 

For example, assume this plus argument is used to launch a simulation: 
+vera„load= router 1 . vro 

Using this plus argument. Vera loads routerLvro and runs the testbench routerl. When the testbench 
is completed, control passes to the interactive prompt. To dynamically load a second testbench, enter: 

$ reset 

Svera_load(*router2 .vro*) ; 
This example resets the simulation and runs the testbench router 2. 

The Svera Joad and $vera„inload commands explicitly set the name of the files to be run with the 
simulation. A reset and restart causes the same testbench to be run again. This allows you to quickly run 
testbenches again and again. If you want to run a second set of testbenches after the first, you must ex- 
plicitly set the new files to be run. 



Note - If the new testbench has a different interface specification, has 
different global variables, or declares different HDL tasks, the shell file 
produced at compile time must change. In this case, you must recompile the 
source code. 



For example, if the third testbench uses several object files contained in a Vera list file, cnten 
$reset; 

$vera_load(**) 
$vera_mload(* routers ,vrl* ) ; 

This example resets the simulation. The second line clears the current testbench being used. The thiid 
line specifies the list file to be used with the new testbench. . • 

18.8 Running Vera Stand-alone 

Vera includes a stand-alone, cycle-based simulator. To invoke the simulator: 

vera -run vera^execu table simulator^options ohject^files 
verajacecutable - The vera_executabl€ is the compiled Vera source code bdng run. 
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simulator joptions - The simulator options and their definitions arc listed in Table 18-6. 
Table 18-6 Simulator Options 
Option Definition 

-o Terminates simulation on error 

-f Specifies list of Vera object files to load 

-« Pauses simulation on error 

-t Opens debugger in text mode 

object JUes - Object files used as part of the simulation are listed in the command line, separated by 
white space. 

-e 

The -e option terminates the simulation when an error is encountered. The syntax is: 
-a 

The -f option loads multiple object files from a Vera list file. The syntax is: 
-f filename 

filename - The filename is the name of the .vrl file containing the list of object files to be run. 

The -s option pauses the simulation when an error is encountered. The syntax is: 
When an error is encountered, the simulation pauses until you enter a carriage return, 

Tlie -t option launches the text debugger when an error is encountered. The syntax is: 
-t 

The default setting launches the graphical debugger when an error is encountered. 

Vera stand-alone is a cycle-based simulator, which runs without an HDL description and in conjunction 
with C for high-level modeling. All interface clocks are driven with the same timing. These system 
functions and tasks work differently: 

delayO returns immediately (with a warning). 

get_timcO always returns zero. 
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Note - To use the Vera stand-alone cycle-based simulator, you must compile 
an executable. This procedure is documented in Section 2.6, "Running the 
Vera Stand-Alone Simulator." 
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19. Vera Source-Level Debugger 

This chapter details the Vera Source-Level Debugger. It includes these sections: 

• Overview 

• Interactive Debugging 

• Contexts 

• Debugger Expressions 

• Text-Based Debugger Commands 

• Gr^hical Debugger 



19.1 Overview 

The Vera debugger is an interactive interface that allows you to step through Vera code, granting tre- 
mendous debugging power. It includes an easy-to-use gr^hical front end along with a powerful text- 
based interface. 

Vera incorporates powerful simulation debugging tools within its debugger, including the notion of c^y- 
cles and timing, interface clocks, multiple thread analysis, and support for re-entrant and recursive 
code. These tools allow you to control and observe the simulation from the testbench perspective. 

The Vera debugger is used to debug Vera code, and it does not affect the debugging or execution of oth- 
er HDL code or waveform display tools. Thus, you can use the Vera source-level debugger in conjuitic- 
tion with existing HDL gn^hic packages, HDL debuggers, and waveform displays. 



19.2 Interactive Debugging ' 

Tlie Vera debugger is activated when one of several events occur , 

• A Vera breakpoint is encountered 

• The Vera debugger is invoked from the HDL command line 

• A verification error such as a failed expect or a timeout occurs 

• A runtime error such as an improper bmd or invalid index occurs 

If you want to use the graphical debugger while running a simulation with an HDL, you must run tlie 
simulation with the +vera_debug_on_etTor plus argument for Vcrilog (see Section 18^, "Running 
Vera with HDLs**) or the vercuini token vcra_dcbug_on_crror on for VHDL (see Section 17.3*2, 
DL Plus Arguments**). 

You should compile all Vera source fUes with the switch if you want to run the Vera debugger with 
all symbolic information for the files included. 
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19.3 Contexts 

In Vera, a context refers to a thread of execution. Vera assigns each context a unique ID internally, 
which is used to identify contexts within the debugger. When using the debugger, you can switch be- 
tween contexts to examine code execution in any context within the simulation, 

A new context is generated under several circumstances: 

• A Vera simulation is launched 

• A fork is executed 

• A function or task is called 

Note that because Vera allows non-blocking forks, a procedure may finish, but its context may still be 
alive (as children it has forked may not have finished yet). This is the reason for assigning a context not 
only to each fork, but also to each procedure call. 

The context determines the variables that are visible in the debugger. The variables in the current con- 
text are always visible in the debugger. This means that any local variables as well as global variables 
are visible. If shadow variables are used within a fork context, they are visible and hide variables of the 
same name in the parent context. 

19.4 Debugger Expressions 

The Vera debugger supports a subset of the valid Vera expressions. Expressions can contain variables, 
interface signals, and integer constants. Expressions can also contain these operators: -, *, /, %, &t I, \ 

t-, &&, II, «, », <, >, =>• 3=. =. and !?=. Expressions can also contain 

these unary operators: !, &, I. -I, and 

Expressions can use variables. However, the expression can only be evaluated if the variable is visible 
in the current context 

19.5 Text-Based Debugger Commands ^ ; 

When the text-based debugger is launched, you can enter commands at the debugger prompt A com- 
mand consists of a single line of input, starting with a command name. Multiple commands can be is- 
sued using semicolons (;) to separate tiiem. If there is a conflict between an identifier and a Vera 
debugger command, preface the identifier with a slash (/), For example: 

print \print 
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The valid text-based debugger commands are listed with a brief definition in Table 19-1. 
Table 19-1 Vera Text-Based Debugger Commands 



Command 



Denoition 



bre&k line^mm 

claar broak line^ntim 

show break 

print exp 

assign var=expr 

show vara 

sbofv context 

source file filename 

end 

echo ^string* 

context context^id 

up 

doiini 

^ere 

list llne^num, ilines 
show £ile 
watch add *ej^p' 



Continue 
Step 

Step in context 

Next in context 

Set break point 

Clear break point 

Show break points 

Prints value of expression 

Assigns value to expression 

Shows accessible variables 

Shows active context lists 

Reads coinznands from a file 

Terminates a source file 

Echoes a string 

Switches contexts 

Changes to parent context 

Chemges to child context 

Shows current location 

Lists source of context 

Shows source files 

Adds a watch expression 



watch change watch^id *exp" Changes a watch expression 
watch insert watch_id *exp' Inserts a watch expression 



watch 
show watch 

save filenaxne 

restore fi 1 ename 

^piit 

close 

help 

radix nunubase 
window 



watcb^id 



Removes a watch expression 
Prints the watch list 
Saves environment settings 
Restores environment settings 
Exits the simulator 
Closes graphical d^ugger 
Prints debugger commands 
Sets the default radix 
I<aunches graphical '*debugg<ir 
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19,5,1 Execution Control 

The Vera debugger has several commands used for execution control. 

The . command is used to continue the Vera simulation. The simulation continues from the last break- 
point or error point 

I 

The , command is used to step through the Vera program. The very next executable statement in the 
Vera program is executed, regardless of context, and the simulation stops. 



The ^ command is used to execute the next step within the current context When this command is in- 
voked, the very next Vera statement within the current context is executed, and the simulation stops. If 
other code must be executed before the next statement in the context is executed, that code is executed. 
This command executes the next step in the context unless that step is within a fork/5oin none. In that 
case, the fust line after the fork/join none is executed. 

If 

The „ command is used to execute the next statement within the current context Statements within sub- 
routines and forks are not executed with this command. Instead, the first statement after a subroutine or 
fork is executed. 

break 

The br^k command sets a break point at the specified line within the specified file. The syntax is: 
break filename^ line^nwnber 

filename - Hit filename is the filename in which the break point is to be set If no filename is set the 
current file is used. 

Une_number - The line^number specifies the line where the break point is set 
This is an example of a break command: 
break myfile© 53 

clear break 

The clear break command clears the specified break point The syntax is: 
clear break filename^ line^nvinber 

filename - Ihc filename is the filename from which the break point is to be cleared. If no filename is 
set, the current file is used, * ' ""^ ^ 
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line_number - The linejnumber specifies the line where the break point to be cleared is. If no line 
number is specified, all breaks in the specified file are cleared. 

This is an example of a clear break command: 

clear break myfile© 53 

show break 

Tlie show break command lists the active break points in all files of the simulation. 

19.5.2 Displaying and Updating Data 

The Vera debugger has several commands used to display and update data, 
print 

The print command evaluates the specified expression and shows the result The syntax is: 

print expression base 
expression - The expression can be any valid debugger expression, including arrays, 

base - The base determines the numeric base of the expression. It must be 0 (auto), 2 (binary), 8 (octal), 
10 (decimal), or 16 (hexadecimal). The default is set with the radix command. 

This is an example of the print command: 

print i+100 

If the expression is an array, you can optionally specify the number of array elements to print: 
print array_name nusi_elements 

If you do not specify the number of elements to print, the current array limit is printed, 
limit array 

The limit array command sets the number of array elements printed with the print command. The syn- 
tax is: 

limit array num^elements - 
The default value is 256. If you do not specify a number, the command returns the current array limit 

assign 

Hie assign command assigns a value to the specified variable. The syntax is: 
assign variable = expression 

variable - The variable can be any variable visible in the current context 
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expression - The expression can be any valid debugger expression. 



Note - Assignments to interface signals are done immediately, without 
waiting for the corresponding drive clock edge. 



show vars 

The show vars conmiand shows the variables in the current context. It displays the data showing the hi- 
erarchy of the call/block structure. For example: 

show vars 

List of active variable at program, main 162 in . . 
File: /foo/foo.vr 

program main 
{ 

integer i; 
integer j ; 

class classjb 
{ 

integer in t„array [50]; 
integer int_asoc [ 3 ; 
task local_array_check 
( 

integer flag, 
integer flagl 

) 

{ 

integer local_var; 



The Vera debugger supports several command used to access context information, 
show context 

The show context command shows the active contexts. For example: 
show context 

Context„ID:406 STATUS: READY 

Location: CALL in program main (cls_dbg.vr, line 162); 

READY in task foo (bar.vr, line 77) 
Context„ID:0 STATUS : CALLING 

Location: CALL in program main (cls^dbg.vr, line 162) 



19.5.3 



Accessing Context Information 
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source file 

The source file command executes commands from a specified file. The syntax is: 

source file filename 
filename - Ihc filename is the name of the file that contains the commands. 
The source file command is particularly useful when the same commands arc issued repeatedly. 

end 

The end command is used to terminate the execution of a source file, 
echo 

The echo command is used to echo a string to the terminal window. The syntax is: 
echo '^string' 

string • The string can be any string of characters, encapsulated by quotes, 
context 

The context command is used to change contexts. Hie syntax is: 
context context^id 

context Jd - The context Jd is the unique numeric identifier assigned to a context If no context Jd is; 
specified, the command returns the identifier of the current context 

up 

The up command changes contexts to the parent context. The parent context is the context firom which 
the current context was called or forked 

down 

The down command changes contexts to the child context If there is more than one chUd context, ike 
command returns a message and the context is not changed. ... ^ , 

vrtiere 

The wfacr« command shows the last executed Vera statement and context For example: 
where 

Location: CALL in program main (foo.vr, line 162); 
READY in task bair (foo,vx, line 77) 



19.5.4 Accessing Source Files 

The Vera debugger provides several commands for accessing source files. 
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list 

The list command lists the specified lines of Vera source code. The syntax is: 
list filename^ iine^number, niim^o felines 

filename - The filename is the filename from which the source code is taken. If ho filename is specified, 
the code from the current file is displayed. 

line_number - The line^number specifies which line of code is the first line displayed. If no 
line^number is specified, the list of source code starts five lines before the current line. 

numjifjines - The num_ofJines specifies the number of lines displayed. If it is not specified, 20 lines 
of code are displayed. 

In the listing, there is a column between the line number and the source code. In that column, an S in- 
dicates a break point, and a > indicates the current line. For example: 

list , 7 

157 trigger (OFF, clsa.which_event (i) ) ; 

158 } 
159 

160 i = 0; 

161 j = 0; 

162 > foo(0, 2); 
163 

164 S i++; 

165 printfCi = %Od\n-, i) ; 

Note that blank lines are numbered but do not count towards the number of lines of code displayed, 

show files 

The show files command shows the names of the loaded Vera source files, 

19.5.5 Watch Commands 

The Vera debugger supports several commands used in conjunction with its watch windows. The watch 
windows are used to show ail the variables in the current context, including global variables, and their 
values throughout the simulation. A second set of watch windows shows user-selected expressions and 
their values throughout the simulation. Each expression in the watch windows is given a unique numer- 
ic identifier used to manipulate watch expressions. 

watch add 

The watch add conunand adds an expression to the watch windows. The syntax is: 
watch add "^expression" base 
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expression - The expression is any valid debugger expression using variables in the simulation. Only 
when the context of the variables is shown will the expression be evaluated. 

base - The base must be 0 (auto), 2 (binaiy), 8 (octal), 10 (decimal), or 16 (hexadecimal). The default 
setting is set with the radix command. 

watch change 

The watch change command changes an existing watch expression. The syntax is: 
watch change watcJ?_nuniber * expression* base 

watch^number - The watch^number is the unique numeric identifier of the watch expression you wait 
to change, 

expression - The expression is the new expression you want to assign to the watch number. It can be 
any valid debugger expression. If the expression is omitted and the base is include^, only the fcojre 
changes. 

base - The base must be 0 (auto), 2 (binary), 8 (octal), 10 (decimal), or 16 (hexadecimal). The default 
setting is 0. If it is omitted, the base from the previous expression is used. 

watch Insert 

The watch insert conmiand inserts a watch expression with a specified watch number. The syntax is: 
watch l&aert ^ratd^nmaber ^expression" base 

watch_number - The watch^number is the unique numeric identifier of the watch expression you wimt 
to insert 

expression - The. expression is the new expression you want to assign to the watch number. It can be 
any valid debugger expression. If the expression is omitted and the base is included, only the base 
inserted. 

base - The base must be 0 (auto), 2 (binary), 8 (octal), 10 (decimal), or 16 (hexadecimal). The default 
setting is 0. The default is set with the radix command, 

watch remove 

The remove watch command removes a watch expression. The syntax is: 

remove watch watab^ntunber 
watch jiumber - The watch^number is the number of the watch expression you want to remove. 
If you do not specify a watch number, all of the watch expressions are removed. 

show watch _ 
The show watch command shows all the current watch expressions and watch number identifiers. 
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19.5.6 Debugging Environment Control, 

The Vera debugger supports several commands for controlling the debugging environment, 
save 

The save command saves the current environment settings to a file. The syntax is: 
save filename 

filename - The filename specifies which file the environment settings are saved to. If no filename is 
specified, the settings are saved to verajiebug^auto.rc. 

The environment settings that are saved include: breakpoints, the current radix, array Hmits, and watch 
expressions. 

restore 

The restore command restores environment settings from a specified file. The syntax is: 
refltoro filename 

filename - The filename specifies the file containing the environment settings to be restored. If no 
filename is specified, the settings are restored from vera_debug_auto,rc. 

quit 

The quit command exits the simulation. When you quit, the current environment settings arc saved in 
the file yerajdebug_auto,rc* 

19.5.7 Miscellaneous Commands 

The Vera debugger supports a set of miscellaneous debugger commands, 
close 

The close command closes the graphical debugger interface, 
help 

The help command lisU the debugger commands with a short definition of each, 
radix 

Tlie radix command sets the default radix. The syntax is: 
radix hase 

base - Tlie base must be 0 (auto), 2 (binary), 8 (octal), 10 (decimal), or 16 (hexadecimal). The default 
setting is 0, The default is 0, >^ . . . . . 
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window 

The window command launches the graphical debugger interface, 

19.6 Graphical Debugger 

The Vera graphical debugger can be invoked from the text-based debugger or launched when the debug 
mode is entered if the -t runtime option is not used. 

The button names and their corresponding text-based equivalent arc listed in Table 19-2. 
Table 19-2 Gra^)hical Debugger Button Dcfinidons 



Button Name 


Text-based Equivalent 


show v&rs 


show vara 


print <exp> 


print 


watch <exp> 


watch add 


uxxw&tch <e)cp> 


watch rexoove 


close 


close 


quit 


quit 


where 


where 


step 




stepc 




nextc 


* f 


cont 




up 


up 


down 


down 


brk <sel> 


break 


clr fark <sel> 


clear break 


auto 


radix 0 


set radix 


radix 



When using the print, watch, and unwatch conunand buttons, you must use the mouse to highlight the 
expression you want to print, watch, or unwatch. 

When using the btk and dr brk command buttons, you must use the mouse to highlight the line you 
want to assign a break to or clear a break fipom. 

19.6.1 Usage Notes 

The current simulation cycle and simulation time are shown in the top bar of the debugger windov/. If 
you are running multiple modules, the module name is also shown in the bar. 
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The watch windows to the right of the debugger interface show the watch expressions and variables 
with their values throughout the simulation. These expressions are only evaluated when the variables 
they include are in the current context (see Section 19.5.5, **Watch Commands"), 

Right-clicking on an expression, array, or class in a watch window invokes an expansion window that 
shows an expanded value of the chosen element Expressions are expanded and shown in their entirety 
when they are selected. When an array is selected, the elements of that array are shown (the number of 
elements shown depends on the array limit). When a class is selected, the class is expanded and shown 
in the expansion window. Further, arrays and classes within expansion windows can be expanded (sin- 
gle values cannot be expanded from an expansion window). 



Note - Expansion windows are static and only show the selected element at 
that moment of time in the simulation. When you step through the program, 
they are cleared. 



The bar under the context window always shows the current context Double-clicking any context in the 
list changes the current context The bar under the file window always shows the current file. Double- 
clicking any file in the list changes the current file. When the current context and current file are sepa- 
rate files, the color of their respective bars does not match. 

Text-based debugger commands can be issued from the command box at the upper right comer of the 
debugger window. 

1 9.6.2 Notes for Tcl/Tk Users 

By default Vera uses a copy of the Tcl/Tk wish shell and libraries, which reside in the Vera directory. 
You need to have Tel 7.5 and Tk 4.1 (or higher) installed and within your path. Note that Tcl/Tk is not 
part of Vera. However, Vera 3.1 and higher includes a pre-compiled version of Tcl/Tk, which gets 
picked up automatically by the source debugger. 

If you want to extend or modify the graphic window, you can edit 

$VERA_HOME/binAerajdebuggerjcl^ create a new version, and use it by specifying your script instead 
of the Vera default, from the debugger prompt: 

window wish^name tcl^fxle ' ,\ ^ 

If you modify this script Vera invokes it as follows: 

wish .*f $VERA_HOME/bin/vera_del>ugger . tcl process^id 
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Appendix A. Quick Reference 

This appendix includes quick reference information in these areas: 

• Vera Files 

• Vera System Functions and Tasks 

• Compiler Switches 

• Vera Debugger Commands 

A.1 Vera Files 

These are the Vera file extensions and their definitions. 



Filename 


Definition 


f ilenaitie. vr 


Vera 


source file 


f ilename.vro 


Con^iled Vera object file 


f ilenaiucvrh 


Vera 


header file 


f il enaine . i f . vrh 


Vera 


interface file 


f ilenaine. vrl 


Vera 


list file 


f ilenajne . vshe 11 


Vera 


shell file 


filename . tes t_top . V 


Vera 


Test-top file for Verilog 


filename. top 


Vera 


top file for VHDL 


f ilename.top . vhd 


Vera 


test- top file for VHDL 


f ilename.intf . vhd 


VHDL 


interface file 


vera . ini 


Vera 


initialization file for VHDL 


filename, vcon 


Configuration file 


filename, pro j 


Project file 


f ilename . shell .V 


Vera 


shell file for multiple modules 



A.2 Vera System Functions and Tasks 

alloc (type, type^ld, type^count [, Jcey_count] ) ; 

Msoc.ittdex {cosamand, array^name^ index) ; 

atobinO ; 

atohex ( } ; 

*tol(); 

atooct ( ) ; 
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backref (index) ; 

bittostr(jbit [high: iov] bit_string) ; 
boxindary (which) ; 

cast.&sslgn ( dest^var, source_exp I , checkl ) ; 

eoiistraiiit„inode ( swi tch I , cons train t^name] ) ; 

coverage ( cojnniand E, object^listl C, "filename'] ) ; 

delay (time) ; 

error ( * fmt_str* ) ; 

error_inode ( type , error_class ) ; 

exit (status) ; 

f cloBe ( file^descriptor) ; 

flag ( [value] ) ; 

fopen {''filename' , * type' ) ; 

fprintf {file_descriptort fmt.str) ; 

freadb (fiie_descriptor) ; 

freadh (fiIe_descriptor) ; 

freadstr ( fil e^descriptor , mode) ; 

get_biad([XD]) ; 

get _bind_id ( hind_expressi on ) ; 

getc { i ) ; 

flr«t_cycle ( ) ; 

get_plus„arg(regrLiest, plus_arg) ; 

get.status { ) ; 

get_status_m«g ( ) ; 

get^systlme ( ) ; 

get_tiiae (vord) ; 

Itoa(i) ; 

lenO; 

niailbox:_get (vait_option, mailbox^id [, dest_var i, check^option} ]); 

jnailboxjut {mailbox_idt data) ; 

mai lbox_recei ve ( wa i t_op t i on , inai Ihox^id ) ; 

iiiailbox„aexad (jnaiIjbox„id, da ta ) ; 

match (pattern) ; 

pack ( array, index , 2 e jf t , ri grh t ) ; 
postxaatch ( ) ; 
prematch ( ) ; 

printf ( * fm t_s tr* , argl , arg2 , . . , , argN) ; 

prodget ( iproduction^name I , occurrence^nvxcherl 1 ) ; 

prodset (value product ion.name E< occurrence_numberl ]); 

putc ( i . * char' ) ; 

guery(conimand [ [ t. Jbin.type] , Jbin_j?attem] , operand, hit}) j 
rand48 ( [seed] } ; 

randjnode ( swi tch [ , variabi e_naine ( , index] ] ) ; 
random ( [seed] ) ; 
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randomi ze ( ) ; 

regioa^eater (vait_option, region^id, valuel, value2f valueN) ; 

rogion^exit {region^id, valuel, value2, . . , , valueN) ; 
rewind (£i J e_descrip tor) ; 
search (pattern) ; 

semaphore jet {wait^option, semaphore^i d , key_weigh t ) ; 
aemaphore jut { semaphore^! d, key^wei ght) ; 

signal.cozmect {port^signal , target^signal I , attributes £ , clocks } ) ; 

sprint f ( s tring^name , s tring^forma t ) ; 

u scant ( s tring^name , s tring^ forma t ) ; 

step ( ) ; 

siabstr{i, j) ; 

suspend.thread ( ) ; 

sync {sync^type, eventl, event2, ... eventN) ; 
thiszaatch ( ) ; 

timeout ( oJbj ect_ type , cycl e^limi t I , obj^ct^i dj ) ; 

trace (reigruest , object I , id.ieveJ] ) ; 

trigger ( [ tri gger^ type , ] even t^name) ; 

unpack ( array, index, left, right) ; 

urand46 ( [seed] ) ; 

urandom( iseed] ) ; 

vea ( swi tch [ ^ signal^name} ) ; 

vera_f ree_arg ( vera_^data ) ; 

vera_jget_arg < index) ; 

vera_nuffi_arg { ) ; 

vera jut_arg ( index , veranda ta ) ; 
vera„retum_value (vera_data) ; 

vsv_call__func(coj3J3ection, tiine_inode, func^name, return^value i, opt^argsl); 
vsv_call_taslc( connection, time^inode, task^name [, opt^argsl) ; 
vsv_close_conn( connection) ; 
vsv_jget_cona_err ( ) ; 

vsr_nayce_client ( *iiost* , port, authentication) ; 

vsv_maJce_server {port , au tiien ti ca ti on I , verJbose] ) ; 

vsv_jup_connections ( timeout) ; 

vsv_wait_f or_done ( ) ; 

vsv_wait_£or_input ( vai t_;node) ; 

waitjhildO ; 

wait_yar (varialjles) ; 
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A.3 Compiler Switches 

These are the compiler switches for use with the Vera simulator. 



Option Definition 

-help Lists valid compiler options 

-cap Compiles Vera source files 

-alim Sets maximxim nuniber of elements 

in arrays 

-ansi Invokes ansi preprocessor 

-g Invokes compiler using debug 

information 

-h Updates .vrh file 

-hnu Updates .vrh file only if it has 

chcinged 

-i Produces ASCII interface 

definition 

-ip Compiles an IP core 



-xnax_error Sets the maximum number of errors 
before compilation failure 

-g Compiles in quiet mode 

-timescale Sets timescale 



-top Creates VHDL top file 

-vhdl Processes VHDL top file 

_D Specifies text macro 

_I Includes directory in search path 

-pp Invokes preprocessor 

-proj Creates Vera shell files from 

project file 

-run Runs simulation 

-tern Invokes Vera ten^late generator 

-c Specifies clock signal 

-d Specifies dump file 

-nav Uses Magellan for simulation 

control 

-t Specifies Verilog module name 

Returns the con5>iler version 
niamber 

-vcon Generates a .vcon file 
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These are the switches for use with Vera-CS* 



Option 


Definition 


-« 


Exits simulation on error 


-f 


Includes .vrl file in the compile 


-i 


Specifies initialization file 


-s 


Pauses simulation on error 




Invokes text-based debugger 



These are the Vera plus arguments. 



Plus Argument Definition 



+vera_load 


Specifies a single object file 


+vera_mload 


Specifies a file with a list 




of object files 


+ vera_s top„on_err or 


Execution stops on simulation 




error 


+vera_continue_on_error 


Execution continues after 




verification error 


+vera_exit_on_error 


Exits simulator on error 


+vera_finish„on„end 


Exits simulator when 




simulation finishes 


+vera_debug_on_error 


Invokes Vera debugger on error 


+ vera_ t ex t_debug 


Launches the Vera text 




debugger on error 


+ ver a_s emaphore^s i z e 


Specifies maximum number of 




semaphores 


+vera_region„si ze 


Specifies maximum number of 




regions 


+vera_^ilbox_si2e 


Specifies maximum number of 




mailboxes 
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A.4 Vera Debugger Commands 

These are the Vera text-based debugger commands. 



Command 



Definition 



break line^num 

clear break line_num 

show break 

print exp 

asaign var=expr 

fibow vara 

show context 

source file filename 

end 

echo string" 

context context_ld 

up 

down 

where 

list lin€_num, 41ines 
show file 
watch add *exp' 
watch change watch_id 'exp' 
watch insert watch^id "exp* 
watch remove watch^id 
show watch 
save filename 
restore filename 
quit 
'close 
help 

radix nuni_Jbase 
window 



Continue 
Step 

Step in context 
Next in context 
Set break point 
Clear break point 
Show break points 
Prints value of expression 
Assigns value to expression 
Shows accessible variables 
Shows active context lists 
Reads coiranands from a file 
Terminates a source file 
Echoes a string 
Switches contexts 
Changes to parent context 
Changes to child context 
Shows current location 
Lists source of context 
Shows source files 
Adds a watch expression 
Changes a watch expression 
Inserts a watch expression 
Removes a watch expression 
Prints the watch list 
Saves environment settings 
Restores environment settings 
Exits the simulator 
Closes graphical debugger 
Prints debugger commamds 
Sets the default radix 
Launches graphical debugger 
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These are the graphical bugger button definitioris. 



Button Name 


Text-based Equivalent 


show v&rs 


show vars 


print <exp> 


print 


watch <exp> 


watch add 


tmw&tch <exp> 


watch remove 


close 


close 


quit 


quit 


where 


where 


step 


# 


stepc 




nextc 




cent 




up 


up 


down 


down 


brk <sel> 


break 


clr brk <sel> 


clear break 


auto 


radix 0 


set radix 


radix 
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B1. Vera-HVL: The Language 



B1.1 Program Structure 



Vera-HVL 



subprogram file |*-^ 



program file 



program file 



interface dedarat'ons 



^rograin ^ program Dame topbiock 



program name 



identifier 



top block 




{ ) (begin 



^ — I variable definition ^ — 



taslc&function definition 



•^■^ ^ — statement '•-^ 




subprogram file 



interface declarations 



bx! 



task&function definition 
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interface 
declarations 




interface definition 



port definition 
bind definition 
coverage btocf< 
coverage definition 
sysdock patti 




task&function 
definition 





function dedaration 









task dedaration 



exported function dedaration 



exported task dedaration 



function definition 



task definition 



dass definition 



typedef definition 



external dedaration 



HDL task dedaration 



User Defined task&function dedaration 




external 
declaration 




external variable definition 
external task dedaration 



externa! function dedaration 



external class dedaration 



external HDL task dedaration 



enum type definition 
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B1.2 Interface Definition 



interface 
defmltion 



^interface^ interface name ■*^(T^ 



interface signal definition 



interface c{od< 



KD- 



interface name 



identifier 



interface 
si^nai 
definition 






interface 




signal 






signal iist 




smpi&dn/ 






Interface 
stgnai list 




signal name 



identifier 



signal 



smpi&drv 


♦ signattype ^ > ■ 










\ . — . , ' 

depth)-*- integer ^ 


^ signal vca ^ 




sicew 



0^ 



integer 
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negative skew 



negative integer 



signal vca 



rOrrO)rrzU«Unr 



interface 
clock 



signal name -i^CLQCK^ 




HDL path 
to node 




HDL moduie 
name 




HDL signal 



HDL module 
name 



identifier 



HDL signal 



identifier 



> 
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B1.3 Variable Definition 



variable definition 




scalar 
/ variable \ 

\ ^ 1 array I / y. \Ly 
variable 




cx)verage name 



range 



^7^-^ integer "^^^^y^ integer ""^^^ 



scalar variable 



variabie name 



expression 



array variable 



variable name 



Ki> 



array dimen^on 



variable name 



identifier 



array dimension 



integer 



external variable definition 



variabte definition 



ion 1^ 
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B1.4 Expressions 



constant expression 



variabie expression 



expression 



,^^r H expression 



expressior} 



expression "•"^^^^ expression "^^J^^ expression 



size 



integer 



unary 
operator 



expression 



^^^-^ expression -^'^^ 



state expression 





function caii 









concatenation 




binary_numt>er 



octsd_number 



dedntai^number 



hexadedmai^number 




variable expression 



interface 



V I dassl^r^ / 
specifier 



C signal \ 
variabie / 

name 



range selection 



— ^ : integer] / 



range 
selection 
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binary 
operator 




arithmetic operator 



bitwise operator 



iogical operator 




arithmetic operator 




bitwise operator 




iogical operator 




&&) ( If 



1 



relationaJ 
operator 



r 



relational operator 




unary 
operator 




concatenation 




expression 



expression 
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B1.5 Statements 



statement 



block 



assignment 



state expression 



interface slgngJ control 



sequential control constnjct 



subroutine constmct 



cobfock construct 



VSG constnJCt 



»^reakpoint^"»"^T^ 




block . 



C vatiabie definition statement 



Statement 



assignment 



assign expression 



assign 
expression 



<2 



variable expresshn 



assign operator expression 



assign operator 




subroutine construct 




taskcail 



return 




cobiock construct 




coblock 



terminate j-M ; 




cobfock 
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B1.6 Interface Signal Control 



interface signal 
control 




drive 



sync drive 



async drive 



sync 
drive 




async 




drive 


signai 




to drive 



delay offset 



delay value 



delay value 



expression 



signal 
to drive 



interface signal 



t>ind 
name 




<iH 



portname 



range selection 



interface signal 



interface name 



-•-^T^-* signal name 



expect 



sync expect 



async expect 



sync expect 



delay window 



» | expect l^ 



soft 
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async expect 




wndaw 
value 




window value 



expression 



expect list 



^^^—^ or expect \ v 

*^ andexpectl ^ 



or expect 



expect expression 




and expect 



expect expression 



expect 
expression 




signal 
to expect 



interface 
signal 



depth selection 



bind name 



AJl/ signal name 




range selection 



depth selection 



integer 



sample 



variable expression 



KHH 




sync 



syrK expression 



J 
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sync expression 



u 

m 
Q 

m 

uJ 
Q 

rij 
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B1.7 Sequential Control 



sequential 
control 
construct 




ifelse 



expression "••^T)^ 



statement 



statement 



while 



^hiIe ^-»^T^ expression "••^T^ statement 



for 



for foop construct statement 



for loop 
construct 



for 
expr 



expression 



■©- 



for 
expr 



for 
expr 



y state expression \ v 

^ assian expression ^ 



assign expression 



repeat 



^repeat^t^T^^ expression """^T^ 



statement 



case 



, casez 



^asex ^ \ ' ^ Ty* expression -»^7^-»^T^ case item 



default 
case 
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case item 



(*- expression » | 



<i>i 



statement 



default 
case 



randcase 



^efault ^"»^T^-» statement 

/ 



case item 



break 



continue 
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B1.8 User Defined Types 

typedef definition / 7^ /-^ — n r— 1 

f ^edefV-K^classJ-* dassname 



enum 
type 
definition 




enum type 



kJenti^er 



enum element 


identifier 












integer -•^{T^) ^ 



enum value 



integer 
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B1 .9 Functions 



function 
definition 



(' v function 
function W definition } 
^ spec 



list 



function 
definition 
spec 



type 



class 
name 




function name 



^ — portname \ ^ 



external function 
declaration 



function declaration 



exported function 
declaration 




[export 



external function 
declaration 



function declaration 




function 
declaration 



^unctio^-*- type 



function 
name 




with 



port 
name 



args 
list 



■dHD- 



function name 



identifier 



argument 
list 



T 




var 



type 




variable 
rwtme 



-0- 



default 




value 





Mix 



option 
args 



optional 
arguments 



( h—H type 




vaTiat)ie 
r^ame 



default 
value 



optional 
args 



default value 



expression 
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function call 



class 
spec 




function 
name 



actual argument 
list 



expression 



port binding 



port 
binding 



^ » bind name ^ 

^wtth^ *"^ ►{TV» expression ■^{T) 7" 

► variable name ^ 



<<> 



actual 
arg 
list 
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B1,10 Tasks 

/ — \ 



task definition 



task 
definition 
spec 



\ ^ argument / 



task 
definition 
spec 



task name 



■ I J > jasKname > v ■ 



port name 



extemai task declaration 



task declaration 



exported task deciaration 




export 



extemai 
task deciaration 



taskdedaration 




task 
declaration 



task 
name 



with 



port 
name 



argument 
list 



task name 



identifier 



task call 


task 


^ — . — ^ 


\_ 


class 
spec 




name 


\ . 


port 
tending 





■0- 



actual 
arg 
l^t 



B1.11 Ports and Binds 



port name 



klentifier 



port signal name 



hentiGer 
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bind definition 



port name -* 



bind name 



port 
signai 
name 



interface 
signal 
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B1 .12 Classes 



class 
defmhion 



class 
definWon 
spec 



dass I 1 dass 

C variable ^ constraint ^ ^ task&fnt ■•^ 
def A def ^ f def ^ 
<^ . ^HjK 



dass 




definition 




spec 






-H^ virtual) — 


class variable 




definition 


dassvariabie 




attributes 



name 






variable 






definition 





block of variables 
definition 




class variable 
attributes 



dass variable 




dassvariabie 




dass variable 


visibility 




randomization 




paddng 



class variable 
visibility 




block of variables 
definition 



dass 
name 
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constraint 
definition 



constraint 
name 




constraint 



1 



constraint 


ciass 




random fiefd 



refationai 
operator 



expression 



ciass 
random fieid 



variabiename 



class tasfc&fnt 
definition 




extemai class deciaration 



c/ass 

^ ^ tasK&tnt K^. 

dedaration \ ( deciaration \ 

— ^ — A^'— — ' Arr 



c/ass 
task&fnt 
deciaration 



c/ass variable 



deciaration 


variat^e 




definition 


class taslc&fnt 




deciaration 





task declaration 



function dedaration 



new expression 



— "^^^^ ^^^^^^ -**^T^ ^ 



dass instance 
name 



class Instance name 



kientifier 



constraint name 



identifier 



class 
specifier 




dass instance name 
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B1.13 Coverage Blocks 



coverage 
block 



(cover.ge_block> <?> 6^%. <>> 



coverage 
block r^ame 



identifier 



coverage 



block body 


vector 




state 




dedaratior} 




declaration 



V state J transition y y . y 

dedaratlon ' ' ' — '"'^ 



transition 
dedara&on 



coverage 
option 



vector declaration 



^vectoM > interface signal *C ; V*- 



declaration 



^ state ^ sfate name number "''^T^-*- 



transltlon 
declaration 




start state 



state name 



destination state 



state name 



state name 



kientHer 



coverage 
option 




■ ^megal,state^ — 



iUegaI_seIf.transition 
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B1.14 Coverage Objects Definition 



coverage 
definition 



^overage,de^-» 



coverage 
name 



monitored 
argument 




\ 


coverage 
definition 
argument 


/ 











0- 



coverage 
definiUon 
body 



coverage 
name 



identifier 



monitored argument 



scalar variable 



coverage defmition argument 



scaiar variable 



coverage 
definition body 




coverage 
case btock 



(3KIH 



expression 




) W { 



coverage 
case hern 



1 



coverage 
default case 



coverage 
case item 




coverage 
default 
case 



^efaid^-»^T^->" coverage definition body 



coverage 
specification 
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state 
specification 




coverage 
conditbnal 



coverage state name 



idenii^er 



coverage conditional 



^7^-»^7^-^ expression *'"^T^)^ 



state 
range 



low 
value 



-0- 



high 
value 



e)g)ression 



step 
value 






repeat 
vaiue 









7 



> 



transition 
specification 




bad_trans 






coverage 




transiHon 




item 



coverage 
transition 
item 



coverage 
transition 
name 



■ay 




cov 




cov 


state set 




State set 



1 



not Hn trans ] 



<>> 



coverage transition name 



identifier 
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coverage 
state set 





state 






reference 







state reference 




coverage state name 



coverage regexp 



coverage state name 



coverage state name 



state range 




low value 



expression 



high value 



expression 



Step value 



expression 



repeat value 



expression 



coverage regexp p^^^— 

coverage goal / \ i 1 

f coverage_goal V-»( = j-^ expression ; V-*- 



coverage value 



expression _,yTV^ 
witti optional quenes Ajy^ 



expression 
with optional queries 



expression 



coverage option 




new coverage 
expression 



monitored 
value 



argument 



coverage 

actual 
argument 




J 
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monitored value 



epxressfon 



trigger argument 



sync 



sync function 



coverage 
actual argument 



expression 



Q 
m 
H 

m 
a 
n 

01 

yj 

a 

u 
m 

Q 
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B1.15 Vera Stream Generator 



VSG 
construct 



start 
producdon 



production 
de(^amb'on 



Cdedamtion ^\ ^ 



prodact'on 



start production 



production name 



production 



production name 





production 
alternative 




weigtit ^ 






production alternative 




production name 



block 



control 
non terminal 




weight 



controi 

non 
terminal 



■^&^-*-^7^^-*- expression -•^^Ty^ 

repeat ( 




■ ^repeat^ -^^T^y*- expression -1*^7^ 



production name 



expression 



expression 



✓--N. I randseq J 
-•4 ) ) » ^ > case — ^ 
item 



rarxiseq 
default 
case 



randseq case item 



expression m. >f : w production name 





randseq default case 



^defaulty >^Ty» production name 



production 


-*^r- , V^' 


name 




production 
name 
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production type 
deciaration 



production name 



T 



production name 



identifier — 



m 
o 
a 

m 
m 

a 

m 
a 
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B1.16HDL Tasks 



HDL task 
declaration 




instantiation patii 




HDL module 
name 



1 



HDL task \ *(2y* 



HDL tasic 



identifier 



extern HDL 
task deciaration 




B1.17 UDF Declarations 



User Defined 
task&functlon declaration 




function 




udfname 



KI> 




argument 
list 




udfname 



(DA 



identifier 



udf function 
call 



udfname 



actual 
argument 
list 



<5> 



udf task 
call 



udfname 



KI> 



actual 
argument 
list 



<>K1> 
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B2. Vera System Tasks & Functions 



B2.1 Concurrent Control 



trigger task 




event variable 



idenSfier 



sync function 



alloc 
function 



variable 




number of 




regions 





aUocW ( 



inft 
vaiue 



MAILBOX 



mallboxid 



numt>erof 
mailboxes 



region id 



integer 



mallboxid 



Integer 



semid 



I integer 



■0-0- 
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init value 



integer 



semaphore 
get function 



^emaphore_get^-»^( 




value 



integer 



semaphore 
put task 



^semaphore jut )-.^(^ ^ sem id va/ae ^ KZ)"KZ^ 



region 
enter 
function 




region exit tasic 



{^o^^ty^^T)^ region id 




maiibox send tasic 



maiityox receive 
function 



— ^NO WATT ^ ^ 



bit vaiue 



expression 



timeout tasic 




SEMAPHORE 



{mailbox^ 




cycies 



Integer 



wait child tasic 



Synopsys inc. 



Vera 4.0 User's Manual 



Appendix B. Vera 4,0 BNF Diagrams 831 



B2.2 String operations 



/en function 



string name 



getc function 



string name -^^T^--> ^ctc ^-»^Y position '^^J^^'^^^jy^ 



putc ta$l< 



string name integer -"^(TV- expression "'"(^^V^^ 



get status 
function 



string name -»^Ty* ^get_statiis^ ^ 



get status message 
function 



string name -*^T^^ geLstatus_msg^ ^i"^^^ 



substring 
function 



string name h (T H position h ^^y^^J^ 



search 
function 



stringnam^ string "'^^^^"^(T^-^^ 



match 
function 



string name \ -<^(Zy-t ^T^ legexp 



prematch 
function 



string name ■»^T^"* ^prematdiy *>^7 



postmatch 
funcUon 



string name -»^T^-»" ^ostmatcfa^ -^^ 



thismatch 
function 



stringname -"^^T^- ^thismatcfa^ ^^ 



backref 
function 



stringname -^^{^^7y-* ^zdm integer """(TyKZ^ 



atoi function 



stringname N ^^W^V^ 
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itoa task 



stringna^ integer "''(^2!^)^^ 



atohex function 



atooct function 



atobtn function 



stringnan^ 



bittostrtasic 



string name [ -■>(Ty» ^bittost^ ^ expression 



string name 



variable name 



position 



integer 



regexp 



string 
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B2.3 Input/Output 



fopen function 




filename 



identifjer 



f close task , 



freadb function 



freadfi function 



freadstr function 




rewind tasic 



^rewind^ t^T^^ Hie descriptor ■*{T^"KZ^ 



file descriptor 



integer 



printftasfc 



^printf^-i»^7^-^ format string 




fprintftasl( 



me descriptor 




sprintf tasic 



^sprintf )^i^T^ string name -*"(TV H format string 
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B2.4 Coverage Control 




coverage object list 



coverage object list 



filename 




coverage object list 



T 



coverage 
/ *■ block name \ 

\ ^ coverage 1 / \ 



coverage 
object name 



coverage 
object name 



variable name 



file name 



query function 



string\ *(yy^ 



query string function 



* ^num.bin )- 

-^FIRST^ — 



query mode 
param 



query mode 



■^GOAL^ 
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query mode 
param 




bit 
value 



state 
transition 
pattern 



Vjy^ operator ^^^^ 



state&transition pattern i 1 n 

— (^)-» | regexp H J]^)^ 

conditional operator 




conditional value 



expression 



B2.5 VSG Value Passing Support 



prodset 
task 



^rodset^ ->^T^ expression 




production 
name 



■(I>G> 



occurrence 
number 



prodget 
function 



' \ 1 


production name 










occurrence 




V * J 


nuniber 



occurrence number 



integer 
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B2.6 Debug Support 




trace 
task 



(DO 



trace level 



integer 



error task 




error flag handling 
function 



simulation error task 




enorcfass 



error class 




timeout error 



expect error 



run time or driving error 




^meout error 



-— III— iiizzr7__L_ 

(ECSENnMOur) (ecrgntmoot) (ecmbxtmoot) 

^-^- T — T — { — 
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B2.7 Simulation Timing 



get cycle function 



{get,cydey >(T)- 



interface 
signal 



<T>0- 



get time function 



get system time function 




delay task 



{ddzyy -(jy* timeunits "•'{^^"KZ)^ 



Hme units 



integer 



B2.8 Signal Control 



vca task 




interface 
name 




signal 
name 



et bind 
nction 



e integer ^.^^ 
string ^ 



get bind ID 
function 



^get^indJd^ ^N^T^ expression '^(^y^^Cl^ 
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B2.9 Automated Stimulus Generation 



randomize task 



class specifier -t^Zy^ ^snd^ ^^ """"Cl^^KZ^ 



pre-randomize task 



dass specifier -j^^T^-^^ ^pre^randomi^ ^ 



post-randomize task 



dass specifier ■♦^T^-' ^post.randomize^ ^ 



random function 




seed 



integer 



seed 



B2.10 Data compaction 



pack 




function 


dass 




spedfier 



pre-pack function 



dass sped^er'\ '*^\y^* ^ixj^zck^ ^ 



post-pack function 



dass spedfier -*^(^^^y* ^pos^ 



unpack 



function 


class 




spedfier 



pre-unpack function 



dass specffier} -»^7^)H> ^ 



post-unpack function 



dass specifier •^^(^^^^-'-( postjaa^ 
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associative array 



array variable 



byte offset 



integer 



bits to the left 



integer 



bitstotherigiit 



integer 



B2.11 Polymorphism support 



cast assign function 



(cast.assign> <?>^ cgcf Q 



source 
object 



destination object 



variable name 



source object 



variable name 
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B2.12 VERA-SV API 



make server 
function 



^ — *{T}-^ — / 



make client 
function 



^make,cKent ^-»^7^ host -^CTy* VSVport -^^TV^ authentication "••{2^)^KZ)^ 



up connections 
function 



^p,coimectioD^ -->^T^^ timeout 



close connections 
function 



^ose_coi^ -»^T^^ connection 



call function 
function 



. -(wait) . 

fcaU_funcV((V | conn f ^^f/)^ V%»V 

^ ^ — »^no,wait) — / ^ 



remofe 
function 
proto 



remote function 
proto 



<remote 



function 



name> 



optionat 
args 



■dHD- 



call task 
function 



^ ^ ^ * * ^ V^NCWAIt) / ^ I P^to 



remote 
task 
proto 



remote task 
proto 



remote 
task 
name 




optional 
args 



<TH7> 



get connection error 
function 



optional 
args 



{ get_conn,erry i>(T^^ 



expression 
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VSVport 
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timeout 



Integer 
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remote task name 
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B3. Vera Simulator 



vera 
preprocessor 



vera 
preprocessor 
options 



source 
We 








output 





vera 
preprocessor 
options 




-traditional 





I indude dir 



macro dearie 



vera 
preprocessor 
opt'ons 



vera 
compiler 



vera 
compiler 



vera 




'■^max.error^ ir^teger 



dmescales^ scale "•^^^^^ 



top nte 
vhdl 




src 



vera 
compiler 
flags 




verllog 
simulation 



magellan 
simulation 



— *^eruJ-»^ximW veritog ^ 1 i 




root 
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p!us argument 



0- 



template 
generator 



continue_on_error 



■■>> ^era_stop_on_erro^ 

-» ^era_exit_on_erro^ 
■» ^era_liiiish^oiCcn^ 
--» ^era,tcxt_debug^ 




vera_seinaphore_size„ 
^era^regioiijze^ 



vera_iiiaObox_size_ 



>^era„inload=^ 



top verilog 
module 




^^y*- dumpfile 




ventog 
file 



vera 
standalone 
executable 




vera 
pretty printing 



I vera y 
source I » 
/7/a 



printer 
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Appendix C, Perl Expressions 



Character 


Description 




Matches any character (other than a newline) 




Groups a series of elements 


\ 

+ 


Matches the preceeding pattern 1 or more times 


? 


Matches the pattern 0 or 1 time 


» 


Matches the pattern 0 or more times 


[...] 


Matches a character from the enclosed set 




Matches a character from the negated set 


(...1... 1 ...) 


Matches one of the alternatives 


A 


Matches the beginning of a string 


$ 


Matches the end of a string 


{ivm) 


Matches the pattern from n to m times 


M 


Matches the pattern exactly n times 


{ivl 


Matches the pattern at least n times 


\n\tetc 


Matches new-line, tab, etc. 


Vb 


Matches on a word boundary 


\B 


Matches inside word boundary 


\d 


Matches a digit 


\D 


Matches a non-digit 


\s 


Matches white-space 


\S 


Matches non-white-space 


\w 


Matches an alphanumeric character 


\W 


Matches a non-alphanim-ieric character 
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Abstract 

We present Ketchum, a tool that was developed to 
improve the productivity of simulation-based 
functional verification by providing two capabilities: (1) 
automatic test generation and (2) unreachabifity 
analysis. Given a set of "interesting" signals in the 
design under test (DU7), automatic test generation 
creates input stimuli that drive the DUT through as 
many different combinations (called coverage states) 
of these signals as possible to thoroughly exercise the 
DUT. Unreachability analysis identifies as many 
unreachable coverage states as possible. 

Ketchum differs from the previous published results 
for several reasons. First, Ketchum provides 10x 
higher capacity than previous published results. The 
higher capacity is achieved by carefully orchestrating 
simulation and multiple formal methods including 
symbolic simulation, SAT-based BMC, symbolic 
fixpoint computation and automatic abstraction. 
Second, Ketchum performs not only automatic test 
generation but also unreachability analysis, which 
enables the test generation effort to be focused on 
coverage states that are not unreachable. Third, the 
backbone of Ketchum is an off-the-shelf commercial 
simulator. It enables Ketchum to reach deep states of 
the design quickly and supports simulation monitors 
through the standard API of the simulator during test 
generation. 

We applied Ketchum to several industrial designs, 
including the picoJava microprocessor from SUN and 
the DW8051 microcontroller from Synopsys and 
obtained very promising results. The experiments 
show that Ketchum can (1) handle design blocks 
containing more than 4500 latches and 170K gates, 
(2) reach up to 6x more coverage states than random 
simulation and (3) identify a majority of the 
unreachable coverage states. 



1. Introduction 

Functional verification checks if the functionality of thie 
hardware design meets the specification. A typical 
method for "bullet-proofing" the functionality of thie 
design is random simulation [11]. Random simulation 
can leverage today's fast sinnulators and computer 
farms by using some sophisticated test harness. 
Verification engineers need to build a model of the 
environment in which the DUT operates. During 
random simulation, biased pseudo random 
generators drive the primary inputs of tl"ie 
environment model with random values and thie 
environment model then drives the primary inputs of 
DUT with random but legal stimuli. The behavior of 
the DUT can be checked by simulation monitors 
during the simulation. We call the model that consists 
of the DUT and the environment model the model 
under test (MUT), 

To measure the quality of the verification effort, 
verification engineers apply coverage metrics to 
estimate how thoroughly the input stimuli have 
exercised the design. Coverage metrics directly 
based on the source code of the RTL design, such as 
line coverage, are too weak because they do not take 
the concurrency of hardware designs into 
consideration. Consider two finite state machines 
(FSMs) that control a buffer (see Figure 1). 




Figure 1. Two FSMs that control a buffer 

The first FSM represents the operation that is being 
performed on the buffer, the second FSM the status 
of the buffer. It*s possible to achieve 100% line 
coverage on the corresponding RTL description by 



exercising only 3 cross-states: idle/empty, 
write/normal, read/full. However, interesting corner 
cases such as read/empty (reading when the buffer is 
empty) and write/full (writing when the buffer is full) 
could be left un visited. 

State coverage, on the other hand, can distinguish 
different concurrent events. Given a set of interesting 
signals, which we call coverage signals, the state 
coverage measures how many different combinations 
of the values of the coverage signals have been 
reached during simulation. We call each combination 
a coverage state. For the above example, if we select 
the set of signals that encodes the states of the two 
FSMs as our coverage signals, 100% state coverage 
indicates that all nine cross states have been visited. 

Coverage signals are usually selected from signals 
that constitute pipeline control, interacting FSMs, 
decoder outputs, status registers or other key control 
signals. By forcing the design into many different 
coverage states, the probability of detecting errors is 
increased. For the above example, a simulation 
monitor may detect that some valid data in the buffer 
is mistakenly over-written during a write to a full 
buffer. Therefore, verification engineers may want to 
construct input stimuli to maximize the state 
coverage; that is, to reach as many coverage states 
as possible. This task is known as coverage-driven 
test generation. Today it can be achieved by manually 
writing test sequences, or tweaking the biasing in 
random simulation. However, this approach is very 
expensive in terms of engineering resources. 

Alternatively, formal methods like symbolic fixpoint 
computation and symbolic simulation can 
exhaustively search for an input sequence to hit a 
coverage state. Recently many formal and semi- 
formal (mixture of formal and simulation techniques) 
methods [1][7] have been proposed for this 
application. However, existing results in the literature 
suffer from a serious capacity limit, as they were only 
demonstrated on design blocks with less than 500 
latches. 

Our contribution is the development of a practical 
solution, Ketchum, to automate the test generation 
process for verifying real-world designs. Given (1) a 
synthesizable MUT and (2) a set of less than 64 
coverage signals, Ketchum automatically (1) 
generates test sequences to reach as many coverage 
states as possible and (2) identifies as many 
unreachable coverage states as possible. The 
generated high-coverage tests can be replayed during 
regression tests. Simulation monitors written in 
arbitrary languages communicating to the standard 
API of the commercial simulator can be used during 
test generation for catching bugs. 



The target capacity of Ketchum is to handle 
synthesizable MUT in the range of 100K gates and 5K 
latches. This range encompasses design blocks of 
integral functionality and many IP blocks, to which 
random simulation may be applied today. 

Ketchum's unreachability analysis employs symbolic 
fixpoint computation [12] and robust automatic 
abstraction techniques to prove many coverage states 
unreachable, its automatic test generation utilizes a 
combination of simulation and formal methods like 
symbolic simulation [1][4] and SAT-based bounded 
model checking (SAT-based BMC)[2], to generate 
input sequences to achieve high state coverage. 

More specifically, random simulation and fomnal 
methods are interleaved to perform a deep and wide 
exploration of the state space. Starting from a given 
initial state, random simulation quickly hits several 
new coverage states but will eventually stops 
reaching new coverage states so quickly. Then one of 
the formal methods is used in an exhaustive search 
for a new coverage state. This search is narrowed to 
just those states not yet proven unreachable. The 
process then repeats, leveraging the ability of 
simulation to search deep, and the ability of formal 
methods to search wide. 

We applied Ketchum to several industrial designs, 
including the picoJava microprocessor from SUN and 
the DW8051 microcontroller from Synopsys and 
obtained very promising results. The experiments 
show that Ketchum can (1) handle design blocks 
containing more than 4500 latches and 170K gates, 
(2) reach up to 6x more coverage states than random 
simulation and (3) identify a majority of the 
unreachable coverage states. 

The remainder of the paper proceeds as follows. 
Section 2 describes our method for generating input 
sequences to reach coverage states, and Section 3 
our algorithm for proving coverage statejs 
unreachable. Section 4 presents the experimental 
results. Having defined the problem and explained our 
approach in detail. Section 5 describes related work, 
and finally Section 6 concludes the paper. 

2. Test Generation 

We present a test generation algorithm that combines 
(1) random simulation, (2) symbolic simulation and (3) 
SAT-based bounded model checking to generate 
stimuli to reach coverage states. We will first provide 
a brief overview of these three search techniques. 

A state (resp. coverage state) of a design is a 
valuation of all signals (resp. coverage signals) of the 
design. Given a starting state, random simulation 



automatically generates a trace of the MUT from the 
starting state by driving the primary inputs of the MUT 
with random values. During the random simulation, 
we observe the values of the coverage signals. If the 
values of the coverage signals indicate that a new 
coverage state has been reached, we store the new 
coverage state and mark it as reached. The 
advantage of random simulation is that it is extremely 
fast and it can generate traces that reach very deep 
states in the state space. The disadvantage is that it 
only searches along a single trace at a time. We 
perform random simulation using a commercial 
simulator. Note that off-the-shelf simulators usually 
perfonn much better in generating a single very long 
trace than a lot of short traces where the simulator 
needs to be injected with the same starting state over 
and over again. We use random simulation as our 
long range search engine to reach deep states. 

Symbolic simulation drives each primary input of the 
MUT with a new symbolic variable at each simulation 
step [4]. It computes the symbolic formula for each 
signal according to the logic in its fanin. Notice that 
the DUT will be driven by legal symbolic formulas 
because of the environment model in the MUT. The 
symbolic formulas are stored as Binary Decision 
Diagrams (BDDs) [3]. Given a starting state, the Mh 
step of symbolic simulation can reach any new 
coverage state that is / steps away from the starting 
state. We store the unclassified coverage states as a 
BDD, called unclassified BDD. During symbolic 
simulation, we check if a new coverage state has 
been reached by substituting the coverage signals in 
the unclassified BDD with the symbolic formulas of 
the coverage signals. If the result of the operation is 
not the empty set, a new coverage state has been 
reached by symbolic simulation. In that case, we 
update the unclassified BDD and generate a trace to 
be used in simulation, as discussed later. Otherwise 
we continue performing additional steps of symbolic 
simulation until a new coverage state is reached or 
some memory or time limit is reached. 



Table 1. Comparison of Search Engines 



Engine 


Effective 

Search 

Range 


strength 


Limitation 


Random 
simulation 


Long 


Deep 
states 


Single trace 


Symbolic 
simulation 


Medium 


Designs 
with fewer 
inputs 


Time, memory, 
length of trace 


SAT-based 
BMC 


Short 


Short hit 
traces 


Time, length of 
trace 



Two important observations about symbolic 
simulation can be noted. First, the number of 
symbolic variables that have been used during 
simulation has more impact on the complexity of 
symbolic simulation than the number of latches in the 



MUT. The number of symbolic variables used in the 
symbolic simulation is the number of primary inputs 
times the number of simulation steps. Second, when 
the size of the BDD that represents the simulation 
values gets unwieldy, we can easily under- 
approximate the symbolic simulation values by setting 
some symbolic variables to Boolean constants [1][6]. 
As a result of these two observations, we can 
efficiently perform symbolic simulation on designs 
with thousands of latches and hundreds of primary 
inputs for 10 to 50 steps. Because of our first 
observation, symbolic simulation generally is not 
adequate to generate traces to reach coverage states 
that are more than a few tens of steps away from the 
initial state. Thus, we use symbolic simulation for 
middle-range exhaustive (or semi-exhaustive wiith 
underapproximation) search. 

SAT-based BMC was introduced in [2]. Given a 
particular starting state, we can use a SAT solver to 
search for a trace up to a certain length / to reachi a 
new coverage state. The targeted coverage states 
can be restricted to coverage states that are not yet 
reached or proven unreachable by the unreachability 
engine. Within a certain time limit, a complete SAT 
solver [14] will: (1) find a trace to reach a new 
coverage state, or (2) prove that no new coverage 
states can be reached by traces up to length /, or (3) 
return no conclusions. If the outcome is (2) or (3), v/e 
apply the SAT solver to search for traces of length 
/+7, until some memory or time limit is reached. For 
designs with thousands of latches and hundreds of 
inputs, SAT-based BMC usually requires a lot less 
memory and is a lot faster than symbolic simulation 
for finding traces of length less than 10. 
Consequently, we use SAT-based BMC as our short- 
range exhaustive search engine. 




Figure 2. Test generation algorithm 

Knowing the advantages and disadvantages of each 
search engine (summarized in Table 1), we 
orchestrate the search engines to hide tlie 
disadvantages and exploit the advantages of 
individual engines. We want to perform a deep and 
wide search by randomly simulating to a deep state 



and, starting from that state, a short or middle range 
wide (exhaustive) search using SAT-BMC or symbolic 
simulation. 

Figure 2 illustrates the test generation algorithm. The 
rectangular box represents the entire state space of 
the MUT and the stars represent the coverage states 
in the state space. The algorithm starts off by playing 
an initialization sequence provided by the user to 
reach the initial state of the MUT (a). Then, we 
perform random simulation (the generated trace is 
represented as the zig-zag line) and quickly reach 
easy-to-reach coverage states. 

After most of the easy-to-reach coverage states have 
been reached, the rate of reaching new coverage 
states falls below a heuristic threshold (b). At this 
moment, we kick off our SAT-based BMC with the 
current state of random simulation as the starting 
state. If SAT-based BMC does not reach a coverage 
state within the search range, we kick off symbolic 
simulation after that. The search space of an 
exhaustive search engine is represented as nested 
circles in Figure 2. When, the exhaustive search 
engine finds a new coverage state, it generates a 
sequence of input assignments that is then replayed 
by the simulator (represented by the gray arrows). If 
both exhaustive search engines run out of time or 
memory limits without finding a new coverage state, 
we will return control to the random simulator. In 
either case, we start random simulation again and 
repeat this process until a desirable coverage number 
is reached. The final output of Ketchum will be a 
single long trace that traverses all the reached states, 
which is stored in a separate file for use during 
regression testing of the MUT. Since all the traces 
returned by the forma! engines are replayed through 
the simulator, the simulation monitors will function 
correctly just as in ordinary random simulation. 

We noticed that after an exhaustive engine reaches a 
new coverage state, the subsequent random 
simulation run could often reach a bunch of new 
coverage states quickly. We suspect that the reason 
is that among the set of coverage signals, some 
coverage signals are relatively easy to transition from 
one value to another and some coverage signals are 
relatively hard to transition. As a result, after an 
exhaustive engine manages to reach a new 
combination of the hard-to-transition coverage 
signals, random simulation will bump into different 
combinations of the easy-to-transition coverage 
signals, which combined with the new combination of 
the hard-to-reach signals become new coverage 
states. 



3. Unreachability 

Proving coverage states unreachable is a major 
aspect of coverage-driven test generation. Knowing 
the number of unreachable coverage states provides 
a more accurate measure of the quality of a 
simulation test bench. Moreover, knowing specifically 
which states are unreachable allows the reachability 
engine of Ketchum to focus on a much smaller set of 
states. 

The goal of the unreachability engine of Ketchum is to 
provide fast and robust results without necessarily 
trying to detect all of the unreachable states. Sim[)ly 
put, we sacrifice exactness in favor of capacity and 
robustness. To this end, we have designed a 
straightforward algorithm that is conservative: it can 
prove states unreachable, but cannot prove states 
reachable. The basic idea of the algorithm is one that 
has been employed by many others before: perfoirm 
exact analysis on a pruned model of the MUT. 
However, we introduce novel techniques in the way 
we select the latches and the combinational logic to 
include in this pruned model. 

Specifically, we first select a small set of latches that 
includes the coverage signals; the remaining latches 
are treated as primary inputs. Next, a novel cutting 
procedure is used to reduce the fanin of the chosen 
latches, to further simplify the analysis. Then, exact 
reachability analysis is performed on the pruned 
model using BDDs. The computed set of reachable 
states is projected onto the coverage signals. 
Coverage states in the complement of this projection 
are provably unreachable, since the pruned model is 
an abstraction of the original. In the following we detail 
the latch selection and logic cutting procedures of the 
algorithm. 

The latch selection process starts with the coverage 
signals. We then add latches incrementally in a 
breadth-first search (BFS) of the latch dependency 
graph of the MUT until we reach a user-specified limit 
on the number of latches. If all the latches of the last 
BFS level visited cannot be included within the limit, 
then an arbitrary subset from that level is used. 

After a subset of latches has been selected, vi^e 
employ a cutting algorithm to reduce the number of 
variables in the support of the transition functions. 
Experience has shown that even if only 50 or so 
latches are being analyzed, if the transitive fanin of 
the latch subset depends on many hundreds of 
primary inputs and non-selected latches, then later 
BDD computations will be intractable. 



free 

inputs "S 




bound 
inputs 



Figure 3. Definition of min-cut for cutting procedure 

To explain the algorithm we define a few terms. 
Consider the transitive fanin of the selected latches 
(see Figure 3). The bound inputs are the outputs of 
the selected latches. The free inputs are the primary 
inputs and the outputs of the non-selected latches. A 
gate in the transitive fanin of the selected latches is 
bound if its transitive fanin contains a bound input, 
otherwise it is free. Now consider the free gates that 
directly feed bound gates; we call the collection of 
such signals the free cut. The signals on the free cut 
may be con^elated, but they do not depend on the 
bound inputs. Hence, it would appear to be a good 
tradeoff to replace all the signals on the free cut with 
primary inputs, thus removing all the free gates from 
the BDD computations. But, we can do much better, 
for it is not the number of gates that we want to 
reduce, but the number of signals in the support of 
the transition functions. 

To this end, we extract a directed network from the 
signal dependency graph (the graph whose set of 
nodes Is the set of signals and set of directed edges 
Is the fanin relation). The sources of this network are 
the free inputs, and the sinks are the signals on the 
free cut. We then compute a minimum cut of this 
network and replace the signals on the min-cut with 
primary inputs. The min-cut has the advantage of not 
only reducing the number of variables in the BDD 
computations, but also of maintaining more 
correlation relative to the free cut. 

Experience shows that using the min-cut almost 
always produces the same set of unreachable 
coverage states as compared to no cutting at all. 
Furthermore, there are cases where the reachability 
fixed point computation only completes when using 
the min-cut. For instance, in the case of lU, one of 
the experimental results reported below, the cache 
miss signal orlginaily had 1102 variables in its 
support, and reachability could not complete. The 
min-cut procedure reduces the support to 60 
variables, and enables reachability to complete with a 



result that is superior to that of just leaving the cache 
miss signal out of the analysis entirely. 

It is clear that the unreachabiliity algorithm computes a 
lower bound on the number of unreachable coverage 
states of a MUT. In other words, every coverage state 
that was identified as unreachable is really 
unreachable, but an unreachable coverage state may 
be missed due to automatic abstraction. 

4. Experimentai Results 

We implemented a prototype of Ketchum in C. We 
used a commercial Verilog simulator (VCS) as o^ur 
random simulator and we developed in house all the 
other engines. Our symbolic simulator and 
unreachability engines rely on the CD DO package 
[18] for BDD computations. The SAT engine is an 
implementation of the GRASP algorithm [14]. 

We applied our prototype of Ketchum to some real- 
world designs. Table 2 summarizes the experimental 
results on the Integer Unit, Data Cache Unit and 
Stack Management Unit of the Sun picoJava 
microprocessor [16], the entire Synopsys DesignWare 
DW8051 microcontroller, and a commercial bus 
controller design "Bus". Each experiment was run on 
a Sun Solaris server of 4 processors and 4GB 
memory. 

The first 3 columns show the characteristics of ttie 
five designs. The 2"^ column shows the number of 
latches in each design. The 3^^ column shows the 
number of coverage signals. Note that the number of 
coverage states is 2 to the number of coverai^e 
signals. In order to choose the coverage signals, we 
located the control FSMs in the source code of tfie 
designs. Then we chose the latches that encode 
these control FSMs as the coverage signals. For 
example, for the case of DCU, we identified the 
"cache-miss" FSM (6 latches), the "cache-fill" FSM (5 
latches), the "write-back" FSM (8 latches) and the 
"zero-ouf FSM (6 latches). Because ali these FSMs 
are 1-hot encoded, there are at most 6x5x8x6=1440 
reachable coverage states. Among those coverage 
states, Ketchum identified that only 111 are potentially 
reachable and it was actually able to generate teste 
that reach all of the 111 coverage states. Note that 
Ketchum was not told in advance about the FSM 
encoding. 

The 4*^ column shows the unreachability results: the 
number of coverage states that were NOT identified 
by Ketchum as unreachable (the number of potentially 
reachable coverage states) and the CPU time takejn 
by the unreachability analysis. We can see that 
Ketchum can effectively identify the majority of the 
coverage states as unreachable. The number of 



latches that we include in the abstract model is 50 
across all designs. 

In the next 3 columns we compare two automatic test 
generation approaches, random simulation and 
Ketchum, in terms of the effectiveness of reaching 
coverage states. The 5^ column shows the number of 
coverage states reached by random simulation and 
the time taken by random simulation (24 hours). The 
6^ column shows the corresponding results for 
Ketchum. The 7*^ column shows the percentage 
improvement in terms of the number of coverage 
states that Ketchum reached over random simulation. 
We can see that Ketchum uniformly outperforms 
random simulation by a large margin. The exception 
is the DCU unit of picoJava, on which random 
simulation reached almost as many coverage states 
as Ketchum but cost 700x more CPU time. 



Table 2. Experimental Results 
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During the experiments, we provided minimum 
environment models for the designs. We set some 
exception signals (like the test signals that control the 
scan chain) to constants and assigned very small 
probabilities for asserting some reset signals during 
random simulation. The same setting and biasing 
were applied to both random simulation and Ketchum. 
So we believe that it is a fair comparison. 

Since Ketchum needs to analyze the MUT that 
consists of both the DUT and the environment model 
for test generation, the size of the DUT that Ketchum 
can effectively handle decreases as the size of the 
environment model increases. In our experience, 
since the environment model only needs to model the 
interface behavior of the DUT, a reasonable 
environment model of the DUT is usually much 
simpler than the DUT itself, especially if the DUT is an 
integral functional block of the design. 



3- Related Work 
Unreachability Analysis 

Symbolic fixpoint computation [12] is the common 
basis for unreachability analysis. Different methods 
that over-approximate the reachable state space have 
been proposed in [1][5][8][13]. However, these 
methods were designed for approximating reachable 
"states", not reachable "coverage states", so they <jo 
not utilize the fact that the logic that is closer to the 
coverage signals has more impact on the behavior of 
the coverage signals than the logic that is farther 
away. The algorithms presented in [15] perform 
unreachability analysis on the pruned model where all 
latches except the coverage signals of the original 
DUT are treated as primary inputs. However, this may 
leave too many primary inputs to perform symbolic 
fixpoint computation. In [9], a heuristic is introduced to 
reduce the number of primary inputs. Our algorithm, 
on the other hand, finds the optimal cut to minimize 
the number of primary inputs. 

Test Generation 

Algorithms that perform some fomi of over- 
approximated symbolic image computation to guide 
simulation for reaching coverage goals have been 
proposed in [1][8][17]. However, these solutions have 
been ineffective so far in attacking designs with 
thousands of latches, on which even the first image 
computation may not terminate. In [1] under- 
approximated symbolic simulation was introduced to 
mitigate BDD blowup. But according to our 
experimental results, the under-approximation 
technique presented in the paper is too drastic in the 
sense that it often misses coverage states. 

Our test generation algorithm is similar to the SIVA 
system described in [7] in the sense that both 
methods interleave simulation and formal engines to 
reach coverage goals. However, the following are the 
major differences. First, SIVA uses ATPG and 
symbolic image computation while Ketchum uses 
symbolic simulation and SAT-based BMC. We believe 
that using symbolic image computation for test 
generation is not practical. On the simulation side, 
SIVA computes a search tree rather than a linear 
trace, which prevents it from taking advantage of the 
speed and the deep states offered by commercial 
simulators. In addition, with the commercial simulator, 
Ketchum can utilize arbitrary simulation checkers. In 
terms of coverage goals, SIVA was designed for 
maximizing toggle coverage rather than state 
coverage. But in practice, toggle coverage goals in 
the DUT are often relatively easy to reach, so tl'ie 
edge of SIVA over random simulation is slim. At last, 
it was reported that SiVA was only tested on 
examples with around 400 latches whereas we 
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successfully applied Ketchum on real-world designs 
with 10x the number of latches. 

6. Conclusion and Future Work 

We have presented Ketchum, a tool that automates 
the problem of coverage-driven test generation. This 
novel technology combines multiple formal verification 
techniques and random simulation to classify most of 
the unreachable coverage states and reach up to 6x 
more coverage states than random simulation alone. 
At the same time, it can handle designs of more than 
4500 latches, an order of magnitude more complex 
than published formal or semi-formal verification 
results. 

Through the use of a robust abstraction algorithm, 
Ketchum is able to quickly prove most coverage 
states as unreachable. Centra! to this algorithm is a 
cutting procedure that reduces the variable support of 
the transition functions of the abstract model, enabling 
unreachability analysis to complete on big designs. 
On the reachability side, Ketchum employs a novel 
interleaving of simulation and formal verification 
techniques that exploits hard-to-reach coverage 
states. The combination of these approaches greatly 
improves the mobility of the search in the state space, 
thus leading to better coverage results. 

There are multiple directions to extend and improve 
Ketchum. For coverage metrics, we want to extend 
Ketchum to handle transition coverage. For 
unreachability, foremost is an enhanced algorithm for 
selecting a subset of latches that takes more factors 
into account beyond BFS level, such as the number of 
fanins from, and fanouts to, the coverage signals. For 
test generation, we want to improve the 
underapproximation capabilities of the formal 
techniques, as well as integrate additional engines, 
such as sequential ATPG. 
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